- **Epistemic status:** #budding > “The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.” (Donald Knuth, 2021) Developers are expensive assets, and one of the biggest and most frequent problems they face is knowing what and how to work on a specific project. Spending a lot of time working on a product that the users don't want, does not work, or focusing heavily on optimization for assumed use cases can hurt the business. If you [[Understand business objectives of a product]] and [[Understand user objectives]] you can avoid spending a lot of time on something that is not needed. Optimization is a balancing act, much like [[Balance over-performance and under-performance]] for your career, where you must make sure that the application is not buggy and fails on release. Worrying about huge scaling issues prematurely when there is still time does not [[Deliver the most value]] since you are adding extra work for the sake of it. A classic example of a premature optimization issue is to worry about scaling the code for millions of users when only a thousand will interact with the application. The concern is valid, but working on it right now just won't produce any value. Especially, if there is a lot of work involved. The first priority of any product is to [[Get To Know The Users]] and [[Understand user objectives]] incorporating their feedback. This helps the business deliver a product that is what the users want and not waste time on things that may never be needed. The way to do this is to start designing wireframes, mockups, or other parts of the product instead of evaluating cloud solutions, ensuring 100% test coverage, hosting on multi-regions, etc. When you validate a product, you get to create a feature set with the requirements to complete the project. These requirements are the necessary components you need to lead decision for optimizing the solution. A product is not static, either. The feature set might change over time, and by prematurely optimizing it can erase the work that was done since it is no longer required. Most development teams follow agile methodologies and CI/CD (Continuous Integration/Continuous Deployment) workflows to iterate quickly on the product, allowing the business to pivot faster. If any bug happens, the developers have the confidence of getting it released quickly. Even with these workflows and methodologies, premature optimization is still a problem. Developers often have issues with when to [[Limit refactoring code]]. As you are doing your daily work, think on doing work the smart way by identifying situations where premature optimization has or will be done and shipping products that you know will be used. It can always be improved tomorrow. --- ## References - II, W. M. S. (2020). _A Programmer’s Guide to Computer Science: A Virtual Degree for the Self-taught Developer_. William Springer. - Knuth, D. E. (1997). _The Art of Computer Programming_. Addison-Wesley. - Watson, M. (2017, November 28). _Why Premature Optimization Is the Root of All Evil_. Stackify. <https://stackify.com/premature-optimization-evil/>