I have once seen a team spend a lot of time and effort on optimizing the startup time of an application server that worked fine when it was already up and running. Once they had finished speeding it up, they announced their achievement to their customers. They were disappointed to notice that their customers didn't really care about it. This was because the optimization effort was not motivated by the user feedback and was only a bottom-up initiative of the developers. The people who built the system were launching the server multiple times every day. So, the startup time meant a lot to them. But sadly it wasn't that important to their customers.
While making a program start faster is a good thing from an absolute point of view, teams should be careful to prioritize the optimization work and ask themselves the following questions:
- Have I been asked to make it faster?
- Who finds the program slow?
- Is it really slow, or acceptable?
- How much will it cost to make it go faster?
- Is it worth it?
- Exactly what parts of the application need to be fast?
Remember that optimization has a cost, and that the developer's point of view is usually meaningless to customers (unless you are writing a framework or a library and the customer is a developer too).
In the next section, we will learn how to keep our code readable and maintainable.