Like any other product, building Tuist is all about making the right decisions, coding features, and releasing them. Although making decisions is easy if there are only a few people contributing to the project, as Tuist grows, things will get more complicated. To facilitate the decision making process, it’s important to have a framework, a list of principles that we can embrace. Steve Jobs liked to call this the taste of a company/project:
The only problem with Microsoft is they just have no taste. They have absolutely no taste. And I don’t mean that in a small way, I mean that in a big way, in the sense that they don’t think of original ideas, and they don’t bring much culture into their products. — Steve Jobs
What’s the taste of Tuist?
The list below contains the taste or design principles of Tuist. The list has been curated based on the work which has already been done, and we’ll actively update it based on ideas that will come up in the future. Here are the principles:
- Convention over configuration
- Design for failure
- Simple is better than complex
- Implementation details bring little value to users
- Make feedback actionable
- If it can’t be reliable, you’d better not build it
- Swift code that reads like Bash is not Swift code
When you need to make a decision for the project, whether it’s about the code, or about the product, go trough the principles above and ask yourself questions. If you think there’s no principle that helps answer your question, don’t hesitate too make a proposal.