Software Debugged

Performance – in this case meaning a piece of software’s run time speed – is one of those things that always seems to cause problems whenever and wherever it comes up. Unfortunately, I think this is because it is very poorly understood across the software development community in general.

Harking back to a contract I had many months ago, I was tasked with improving the performance of a key component. I asked how much improvement was needed, and although I can’t remember my manager’s exact words, the reply was along the lines of: “It needs to run as fast as possible”. That wasn’t the first time I’d heard such as response, and I very much doubt it will be the last. This is worrying because such statements are basically madness, for the following reasons:

• It indicates the lack of a plan, that the requirements have not been understood, and that people who should know better are basically making things up as they go along; further, it indicates that those responsible for the requirements did not understand that performance requirements are requirements!
• Further, it means developers tasked with squeezing more speed out of a component will possibly (probably?) waste their time doing so. There is no point in spending time trying to get a factor of five improvement, when a factor of two is all that is needed!

Note that I’m not saying performance requirements need to be specified up front before any development can be done. On the contrary, much modern software is developed using agile methods which are designed to allow for changes in requirements during the development lifecycle. However, the fact that requirements can change is not an excuse for not understanding requirements. It does not matter if are requirement has just been updated or has even just been introduced into the project – it must still be understood!

In conclusion, what I’m saying is this: performance requirements are requirements, they must be treated as such and understood before any action is taken.