Why buy a new car window when a roll of duct tape will do?
Let’s say you just got home from work. You’re tired. Sore. You look in the fridge. Nothing. Take out? Why not? But, you’ve also got a wedding to attend in 2 months and the last time you tried on your suit buttons were bouncing off your bathroom wall like a pinball.
So the question becomes, do you take the short-term fix to your immediate problem? Or do you buckle down, power through the walk to the grocery store and make yourself a salad?
This is a problem developers face on a regular basis (well, not this exact problem, but one in the same vein). Often we’re faced with a time where a decision needs to be made between what we think is best practice in writing code, and what is best for the company direction.
Is it worth spending more time writing what we think is ‘good code’ if it means delivering less value to the business in the short term? Or are immediate results all that matter?
What is ‘good’ code anyways?
Where this whole argument becomes sticky is when you ask just what makes ‘good’ code.
It would be a difficult position to argue that code with bugs is better than code without. But, an unfortunate truth that any developer can agree with is that the only teams who come close to achieving this are those at the very top of technical engineering and who have the resources to actually write it.
Here’s an example from the team responsible for the software powering the NASA Space Shuttle:
“The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.”
This is no To-Do list tutorial they are building, so, why is NASA’s software so much better than, say a billion-dollar startup’s? Well, first off, it has to be, as they explain:
“Every time NASA fires up the shuttle, that software is controlling a $4 billion piece of equipment, the lives of a half-dozen astronauts, and the dreams of the nation.”
‘Good’ code, in this case, means one that fit the purpose of the mission. And for NASA, the results of a mistake in the code are huge :
“…a bug that causes a timing problem of just two-thirds of a second puts the space shuttle three miles off course.”
Lives hang in the balance of any tiny miscalculation.
But this ‘quality’ isn’t cheap. And while the software team’s $35 million per year budget is a trivial slice of the NASA pie, on a dollars-per-line basis, it makes the group among the nation’s most expensive software organizations.
What do you value the most?
So, if your code isn’t controlling the fate of human beings hurling through space, and you don’t have a multi-million dollar engineering budget, how do you define what’s ‘good’?
There’s two factors I like to look at:
- Efficiency: Is the code fast?
- Simplicity: Is the code easy to understand and maintain?
While ideally good code will be both, there are situations where these qualities are mutually exclusive and decisions need to be made as to which is more important to you.
Think about Financial Trading Software (FTS) vs. an Open Source Project.
For an FTS, efficiency is king. It will result in faster trades and potentially higher profits. Efficiency is what will get them closer to their end goal.
However, an Open Source Project may think of maintainability as more important. The end goal here is different—it’s to help others use the software and get them involved in building and maintaining it. If the focus is on efficiency and hacking together something that’s quick, people coming into it will have a hard time understanding what’s going on without explanation.
In both of these situations, just like with NASA, ‘good’ code ultimately depends on the outcome you’re after and what your company’s core values are.
Is there pressure for speed? Then ‘good’ is what gets you there quickest.
Do you care more about maintainability and how the code will hold up after a year? Then simplicity should be second to none.
So writing fast, bad code is acceptable?
Looking at these examples, we can start to define ‘good code’ as code that does the job it was intended to do in the best way possible. Whether that’s navigating people through space, trading currencies, or creating open source projects.
But if we define ‘good’ code as another tool for your company’s success then are we sacrificing our own growth and our pride as someone making products?
Some hardliners believe there is absolutely no correlation between ‘good code’ and ‘product success’. And that if the additional time spent on developing ‘good code’ can’t be seen or perceived by customers, why is it worth putting time into?
Also, features and requirements are constantly changing, so why bother? Releasing fast and iteratively allows for tighter feedback loops from customers and better features and experiences for the customer.
As Jeff Atwood, developer and author of the Coding Horror blog, puts it:
“…anything that gets in the way of you fixing your code or improving your code in a way that your customers can appreciate, is a negative.”Jeff Atwood
While it’s hard to argue that the company’s goals have to come first, there is still always a matter of professionalism at stake. You aren’t necessarily hired to just solve the problem, but to bring your own unique set of experiences and skills to the problem and solve it in the best way you know.
Think about a plumber you’ve hired to fit a sink. As they’re putting in the pipe, they can either screw them in properly with brackets or nail them in. The goal is to get the sink in, so nailing is quicker and cheaper.
Same result. Faster process for the customer. Better, right?
Well, if you ever need to do anything with that pipe, like move the sink because you bought a new toilet, you can’t do anything without destroying the wall.
The short-term view to that client is the same either way, but you’re leaving them with a potential future headache.
I believe it’s in our best interest, as well as the company or client’s, to do things in the best way possible. Which means anticipating changes and writing ‘good code’ that solves the current problem, but also is easy to modify and maintain.
Although there’s always the risk that code might get thrown out entirely at some point, ‘good code’ that has been properly thought out will be much easier and faster to make changes to, and as a result, less likely to be thrown out and rewritten.
Plus, the more you write good code, the easier it is to write, the better your code gets over time. You’re not just investing in the product, but in yourself as a member of the team and an asset to the company.
So, does ‘good code’ matter?
It matters to you.
Sometimes the company goal is not killing people. So it’s easy to make the decision between speed and quality. Other times it’s a balancing act of not screwing over your teammates while also keeping higher-ups happy.
The good code you wrote a year ago should be your bad code today. Otherwise you aren’t progressing. If you’re writing what you consider to be bad code you aren’t learning, you’re being lazy.
Writing what you think is good code, which also does what it needs to in the best way possible, means you’re at least trying.
Maybe you’re making mistakes. Maybe there are bugs. Maybe you’re making some sacrifices in the name of speed and changes to the market. But you’re progressing. You’re creating code that lives up to your own standard and will be in a good place for the changes waiting for you around the corner.