How To Write Perfect Code
Have you ever written perfect code? If so, how often does this happen? If not, why not, and do you think it’s possible? Perfect code is something that many developers strive for but few, if any, achieve. In this entry, I will discuss the set of requirements that must be met for a developer to be in a position to write perfect code.
What is Perfect Code?
My definition for perfect code is “Code that solves a problem, without bugs, in an optimal way”. This has slight ambiguities, so I’ll break it down.
1. Solves a problem
The whole idea of writing the code is to solve some non-trivial problem. To do this perfectly, the solution must be solved for all possible cases.
2. Without bugs
The code needs to perform the required task correctly in all situations. This includes valid and invalid input and situations.
3. In an optimal way
I come from a game development background and therefore performance is important. Depending on the situation, optimal will take on a different meaning. For games, this might mean that the entire game loop must run at a minimum of 30 frames per second. For a banking program this might mean that a transaction takes less than 10 second to complete.
Is Perfect Code Possible?
The simple answer is, yes. Code can be written that perfectly solves a problem, without bugs and can therefore be classed as perfect. Unlike many professions, what we create is never fully “set in stone”. Code can change at any level, from fixing a broken statement to re-architecting an entire application. When the three requirements below are met, developers are in the best possible position to write perfect code.
The Requirements (aka What’s Needed To Write Perfect Code)
To expect perfect code from developers, the following 3 requirements must be met:
1. Thorough Domain Knowledge
2. Enough Time
3. Great Developers
Just think about each of these for a minute before continuing. If you’re a developer, do you meet all three requirements in your current position? If not, which ones don’t you meet, and why? Feel free to post a comment.
Below I’ll break down these requirements and show two graphs. One for the amount of return gained for levels of input into each requirement. The second graph shows the cost of achieving a set level of quality.
Each requirement also has a limiting factor. This is the top reasons why developers often write imperfect code.
1. Thorough Domain Knowledge
Developers must have a good grasp on the subject matter they are to be working on. If you’re making a driving game, you need to know the way cars handle, what torque is and why a blowoff valve sounds so cool. If you’re writing an accounting program then you need to be boring, and therefore understand accounting (or is it the other way around). You also need to know about debits and credits and the difference between cash flow and capital.
Moving from no domain knowledge to a simple understanding helps a lot when striving for perfect code. After this point, learning more about the domain helps, however the next big leap in code quality comes from having an intimate understanding of the domain (the small mark on the x-axis in the graph below).
The following graphs show the level of quality gained by increasing domain knowledge and the cost required to achieve this.
It’s difficult to find someone with expert domain knowledge and takes time for people to learn. Also, many developers simply won’t want gain an intimate understanding of the domain. This can be solved by having domain experts work closely with developers. See Domain Driven Design by Eric Evans for an in depth discussion on this topic.
2. Enough Time
Most projects I’ve seen rarely have enough time. Time is critical for writing perfect code as it unlocks the following factors:
- Hacks/quick fixes won’t be written
- There will be little to no overtime
- Peer reviews and pair programming become possible
- Work can be designed rather than simply hacked together
- Work can be thoroughly tested
The mark on this graph shows where “enough time” is given for a project. If enough time is given, the quality in code jumps substantially. After this time though, there is a point of diminishing return as having developers continue to work on the project won’t return great gains.
One point to note is that if the amount of time given to developers changes mid project, all bets are off.
Money is the major limiting factor with giving developers more time. However it isn’t the only one. Competitors can bring products out before yours or customers may have strict deadlines that you must meet. Also, developers don’t live forever, and rarely life in the same job forever. The longer a project runs, the more likely you are to lose developers and therefore have to retrain and rehire more, at great cost.
3. Great Developers
I agree with the concept that good developers are 10 times more efficient than average developers. Joel Spolsky put this perfectly when he said “Five Antonio Salieris won’t produce Mozart’s Requiem.” For those that haven’t seen Amadeus, he’s saying that the order of magnitude difference between good and great developers is staggering. Unfortunately, you just can’t get the quality you need unless you have great developers; it’s as simple as that.
The mark on this graph show’s the level of developer skills required to write perfect code. About the top 5-10% of developers fit into this bracket. The good news is that the difference in cost between an average developer and a great isn’t the same order of magnitude higher.
Great developers are hard to find! With companies like Microsoft and Google paying crazy amounts of money, the top tier will often work for them. However the good news is that great developers can be trained and in the right environment, so long as you have smart people you can often turn them into great developers if they (and you) care enough about software development.
Do We Want Perfect Code?
That may seem like a simple question, however in reality it isn’t. In a vacuum, for most developers that question is rhetorical. Of course we want to write perfect code, we take pride in our work and we strive for excellence. However, when you look at the cost involved in achieving perfect code it is not always a requirement.
This is something we must take seriously when writing software as the realities of business mean that more often than not, imperfect code is exactly what the business needs. It’s better to ship code with issues than to not ship code at all.
I’m sure I’ve said at least a few controversial things, so please comment and/or email me to continue the discussion. I continue to strive for perfect code in my life, and whether I’ll ever reach it is irrelevant. I’ll leave you with a quote from one of my favourite movies:
“There are no perfect men in this world, only perfect intentions.”