Why might premature optimization be harmful?
Think ROI of what you are optimizing
Do you ever regret spending a lot of time and energy on a feature that later gets destroyed?
Are you under constant pressure to build a feature with scalability in mind but with a short deadline?
We can all agree that it’s a painful experience to build something beautiful and immediately asked to discard it.
I’ve been there many times leading software development team. It could be a soul-crushing moment especially for the ones with passion in their craft.
In this post, I will explain why premature optimization can hurt our projects and how we can minimize the pain.
Why do we destroy features?
It makes our stakeholders and clients feel comfortable to see a complete feature that works and looks great like it’s supposed to be in the final product.
A complete feature gives pieces of mind that we are making progress towards a shippable product.
In reality, a feature is done when it proves its value of existence beyond technical and aesthetic implementation.
No matter how DRY the code is, how beautiful it looks, and how resilient it works with automated testing, we have to kill the feature if it doesn’t produce any value for users.
In an ideal world, we would only be asked to build a feature that is already proven to work for the users.
But in reality, the development process is a part of discovering, evaluating, and delivering a valuable product.
The best way to achieve highest ROI on our resource is to focus on why the feature exists, not how it exists.
How can we prevent the premature optimization?
We are prematurely optimizing when we invest a lot of time in building something that has not yet prove its value to users.
Even after conducting a UX research with a clickable high-fidelity mockup, the value of any given feature is still at a risk of its existence until it’s deployed and receive positive user feedbacks.
So does that mean we should just produce a feature with no regards to its maintainability and rough UI implementation?
Of course not.
Many great features survive through for more iterations to tweak and polish, and maintainability is a key to staying agile.
So how could a team focus on investing the right amount of time on the right things?
What should our team focus?
The answer may seem boring: the core logic and basic building blocks.
A typical web application provides its core values by outputting useful information and receiving user input that can be used to achieve user goals.
For example, a doctor could use an application to record patient medical records that can be easily retrieved later.
While logics and algorithms that effortlessly store and output information stay relevant for long-time, implementation details of form design and tabular data output might be short-lived.
In summary, any abstraction logic that is agnostic to implementation detail will stick around longer, and therefore returns the highest return on time invested.
Where can we begin?
The best place to start is at the core of technology we are utilizing.
Instead of investing in special effects and animations, focus on building base component style that is well maintained and compatible across devices and user conditions.
Instead of investing in specialized complex data models, concentrate on building the developer-friendly data structure that is easy to communicate with and well documented.
Once we invest in core building blocks of the application, then many iterations can be done faster without causing a major overhaul.
I’m a front-end developer lead at Fresh Consulting. I write about influential technical leadership (The Pragmatic Question) and latest technology experiments.
