“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” – Donald Knuth: The Art of Computer Programming
This is one of the most repeated truth in our field of business and most follow this by the letter. I follow this. As an architect with deadlines and budgets, it’s important to focus on the right things. There is more to this truth that first meets the eye though, important amendments; “The tax and fines of system performance”.
The tax of system performance is the cost we have to pay, in time or resources, to work on the performance of a given feature or subsystem in our solutions. This tax is not mandatory, it is very much voluntary and you can choose to pay this when the feature is developed or just ignore the tax all together. Just hope that is was a tax you didn’t have to pay. I think that this is what Donald Knuth wants us to to do, don’t pay the tax if you don’t have to.
There is a downside of embracing this methodology in a fanatic fashion, as usual. If it turns out that the tax had to be paid, there will be a fine added to the tax which will increase the total cost . If this happens very late in the development cycle, this fine will be very expensive and sometimes be larger then the original tax costs.
So, premature optimization is bad, but holding off optimization might as well be as bad or even worse. How should we as architects / developers handle this, how are we to know when the tax should be paid to avoid the fine and when we can ignore it?
The answer to this is spelled Performance Budget that should be in the description of features that goes into the project. This budget should clearly state what’s expected in terms of performance. Time to first byte, response time, memory consumption and so forth. Adding this and making sure it is validated before feature check-in, will quickly show you when you need to pay the tax and when you can ignore it without being fined.
A typical performance budget can look something like this:
As a user given an address I can create an order with address information so that I can invoice the client.
Performance budget
–
Saving the order can not take more then 1 second.
Saving the order can not consume more then 1k memory.
As any requirements, defining these are hard work. But it will help you avoid those fines and will cost you less in the end. As any feature description, this text is worthless if the validation never occurs. I will talk more about validating performance budgets, tracking performance degradation and preparing your systems for performance investigation. So keep in touch.
