“Make it work, make it right, make it fast” is a straightforward and disciplined software engineering approach that emphasizes the importance of prioritizing functionality before optimization and technical concerns. First mentioned by Kent Beck, this approach encourages developers to first ensure the code works correctly, then refine it, and finally optimize it for performance. By prioritizing functionality over perfection, developers can meet the needs of their users and stakeholders before focusing on technical details. Although delaying optimization may seem counterintuitive, this approach can ultimately result in better code that is easier to maintain and scale over time.
This approach can also be applied to building a product or startup from a broader perspective. For example, ShareWis recently celebrated its 11th birthday, and our codebase’s first commit was around 2014, making it a 9-year-old legacy project. We have achieved some successes, gained more customers, and received positive feedback on our product. Our next step should be to make it right by developing a completely new front end with more modern tech stacks and rewriting the legacy project with new RESTful APIs. Making it right (and secure) means our product will have fewer bugs and be more stable and reliable for our customers and potential customers. Finally, making it fast by dedicating more resources to performance optimization and UX improvement can help users save time when accessing our pages, and it can also help us save more resources and costs, which is an undeniable competitive advantage.
In daily engineering tasks, it’s important to adopt a “make it work, then make it right, then make it fast” approach. This means prioritizing functionality over optimization and technical concerns. While it’s crucial to ensure a feature works, it’s equally important to continue iterating and improving upon it. Simply “making it work” is only suitable for outsourcing companies or teams. As developers of our own products, we need to strive for more. Otherwise, we’ll end up with a product full of bugs and technical debt, hindering future feature development and improvements.
After making a feature work by implementing all the requirements in the definition of done, it’s time to improve the code design by following refactoring fundamentals and making the code clearer. To refactor safely, ensure to write tests that cover your changes before or after making it work.
Finally, if the implementation isn’t fast enough in terms of performance, it’s time to tune it up. Follow best practices for Rails or SQL performance (such as avoiding N+1 queries, using proper indexes, and delegating calculations to the SQL engine). Learn how to use benchmarking tools, as measuring performance is a must for optimization.
In conclusion, “Make it work/right/fast” is not an option but rather the order in which you should develop any features or complete any small tasks (except perhaps bugs). To improve our engineering team, I think we could take some actions:
• Have a good enough “Definition of Done” to make “Make it Work” equivalent to “Make it Done.”
• Not just stop at “Make It Work”; our team members should learn more about software development principles, refactoring fundamentals, patterns, and best practices, and be able to detect and avoid code smells.
These are the topics we will explore together in future knowledge-sharing articles.
P/S: Bài này mình viết năm Tháng 03/2023, hôm nay nhờ ChatGPT giúp mình tút lại cho hay hơn.