Software Development Philosophy and Performance

Recently I have been working a lot with some people I would call “Old School Developers”. They were brought up in the “glory days” of the pre-internet era of development. I have been tasked with teaching an old dog new tricks. In this case, I am teaching Web Services development using Apache CXF and the Spring Framework to a few C++ developers of 20+ years. These people are really smart and have a good understanding of software development. What they need is a paradigm shift.

When working with these people, I constantly hear concerns about performance. This seems to be the number 1 issue on their mind. They need to be careful that they always achieve the best performance possible no matter how much extra complexity it adds to the code. These constraints even influence the design of the code where fundamental design changes are made for the sake of performance alone.

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)

Programmers are notoriously bad at knowing when to optimize code. We end up focusing on the little things when we really should be concerned with reducing more broad performance issues. Is shaving off a few milliseconds a priority when you are dealing with remote web service call over the internet?

My philosophy on software development is to focus on the most important aspects first. As you might have guessed, performance does not make that list. The most important criteria for

  • Readability – Write Code that is readable. You or someone else will appreciate it when you have to come back to it at a later point in time.
  • Simplicity – Keep it simple. Only build in complexity where required and only to the degree required. You can always refactor it later.
  • Say Less – Less code is more. If you can leverage something that exists, do so.

Do not take this the wrong way. I am not trying to say here that performance is not to be considered or that it is not important. I am simply saying that it is not the most important issue. Once you have good readable and simple code, you can go back and optimize it where it needs it. If you start out with performance as a goal, you will never end up with readable and simple code. No one goes back over working and fast code with the intent to make it slower and more readable.