A junior developer on my team asked me a rather interesting question
recently.
If you were able to make laws, would you make bad code
illegal?
I have a reputation where I work as being rather hard-nosed
about not allowing hard to understand and maintain code into the codebase, so
my answer surprised him.
No, I would not make bad code illegal, and there are very
good reasons for having this opinion.
First, everyone writes bad code before they write good code.
Whether it’s your first time coding in general or just your first time coding
in a new language, with a new framework, etc, you are going to write bad code.
I’m sorry. It’s just a fact of life.
Nobody starts out writing amazing code. Not me, not you, not
Uncle Bob (in fact, Uncle Bob is open about the fact that he was a horrible
developer when he started, just like the rest of us). We all get better by
writing bad code, learning from our mistakes and pain, and, if we’re lucky,
mentors helping us to see where things can be improved.
Second, “bad code” is rather subjective. What standard are
we using for what “bad” code is?
Is it code that costs the business unreasonable amounts of
money due to being full of bugs and difficult to maintain? That’s not a
completely terrible definition because we can tie it to some external
benchmark, but it’s still probably a bad idea since there is a risk/reward
factor of why decisions were made at the time that may not be known at some
later date.
Is it code that Developer X (whether me, Uncle Bob, or Joe
in the cubicle across the hall) would look at and give a laundry list of things
that need to change? For any given code, you can find some developer that would
find flaws in it – whether it is inefficient, or it doesn’t implement their
favorite pattern, or any number of other complaints.
Is it code that, six months from now, you will look back at
and wonder what the heck you were thinking when you did it that way because
there are so many better ways to accomplish what this code does? Here’s a hint.
This should be most of your code. You didn’t know as much 6 months ago as you
do now.
Third, sometimes bad code is necessary.
Yes, you heard me. There are times that it makes sense to
write bad code.
If you are writing a script to perform some one-off function
that you are seriously never going to use again, pretty doesn’t always matter
that much. If writing code for 5 minutes and then throwing it away can save you
hours of work, go for it. I’ve done it before, and I can almost guarantee that
I will do it again.
Sometimes you need to fix a catastrophic flaw in a mission
critical piece of software, because the company is losing millions of dollars
per minute while the flaw exists. In that case, you have to do whatever you can
in order to fix the issue, release the patch, and *then* go back and make it
maintainable.
The same is true if we are in a startup where the money is
limited, time is fairly short (as it is generally a function of money in this
case), and we need to get a Minimum Viable Product out in front of users so we
can start making money. This is another case were “Make it work, then make it
better” can be the correct (and sometimes only) course of action.
We may not like it, but sometimes getting it to work right
now is the right choice. These situations fall under the heading of consciously
taking on technical debt with every intention of paying it back later and this
is a very important business decision. If it’s a matter of “We can release it
now and be able to make payroll” vs “It will take another month to make it
perfect and we’ll be unemployed by then”, well, the choice is fairly clear then
isn’t it?
Thankfully, most of the code we write doesn’t tend to fall
into those categories, so we can make the effort now in order to make the code
clean and maintainable, but we can’t ignore that those possibilities exist.
Making a law that is, on the whole, completely subjective
and capricious is a just plain bad idea. As a general rule, when we write code
that isn’t amazing, at worst we lose time in figuring out what is going on
and/or fixing some bugs. Nobody generally dies from bad code (there are cases
this is not true, but they are not the norm), and we can always make a conscious
effort to improve it once the crisis is averted.
On the whole, yes, we need to strive to write clean,
maintainable, bug free code, but we can’t be completely inflexible. If you want
to make it a crime to write bad code, make the punishment be to learn how to
write better code. I think that’s a fair sentence.
Current mood: Calm
Current music: Midnight Oil – Beds Are Burning
