We All Write Bad Code

10 commentsWritten on January 24th, 2009 by
Categories: Opinions

I recently read a post from J.P. Hamilton where he admits that he sometimes writes bad code. I quote:

That’s a brave admission in our industry, but I am willing to bet that even the best of best write bad code now and then.

I would go even further than that. Any developer who claims he never writes bad code is either lying, ignorant or living in a fantasy world. The thing is, as J.P. points out, is that good developers will try to minimize the amount of bad code that they write, and when they do, that they try to get rid of it as soon as they can. But if those developers are so good, then why do they occasionally write bad code in the first place?

Building software takes resources and requires dealing with constraints. With resources i mean more than just the number of developers that are available to work on a project. Software libraries are resources. Tools are resources. A lot of things can be resources or constraints (sometimes they can be both simultaneously). And obviously, each resource has a certain level of quality, which can have a positive or a negative effect (which enables these resources to also become constraints).

The cumulative effect of all of these resources and constraints means that you sometimes need to make compromises. One of those compromises can be that a good developer comes to the realization that for whatever reason, he (apologies to my 2 female readers: it's not easy to refer to developers in a gender-neutral way all the time ;) ) needs to write bad code to make a problem go away. Code that is not up to his usual standards and that he is not proud of.

This is usually referred to as incurring some technical debt. Nobody likes to incur debt, but sometimes you just can't avoid it. If incurring some debt enables you to start creating value sooner rather than later, then it might actually be a good idea to do so, provided that you have the means to pay back the debt later on at a reasonable cost. You definitely should strive to keep that debt as low as you can (or even eliminate it entirely) because if you don't pay off the debt, you're definitely going to regret it sooner or later.

I honestly have a lot more respect for developers who can identify the need to occasionally write a bit of bad code instead of foolishly clinging to a dogmatic "i shan't write bad code, no matter what the circumstances" stance. Well, as long as they remember to pay off their debts as much as possible, and that they do strive to write clean code as much as possible ;)

  • http://igorbrejc.net Igor Brejc

    Knowing that you write bad code is a virtue in itself. After all, how would you know your code is bad if you haven’t produced any good code? ;)

  • http://skepticabin.wordpress.com/ Eric

    The ubiquitous trade-off – to write bad code or not? The problem isn’t so much in remembering to address the resultant accrued technical debt, but in convincing the people who foot the bill that there is such a thing.

  • http://davybrion.com Davy Brion

    @Igor

    good point :)

    @Eric

    you’re right. i think it’s important to be honest about it with the sponsors up front. If you’re going to have to take some shortcuts you probably should tell them about it up front and warn them that it will need to get cleaned up ASAP. If they choose to ignore that advice… well that’s a whole different story then.

  • http://www.noctovis.net/blog Laila

    @Igor: I wouldn’t even say good code, I’d say better code, since you can probably even improve the last code you wrote.
    Whenever I reopen code (even if it’s last week code) I wrote, I automatically begin refactoring it.

    @Davy: What if management ignores your advice?

  • http://davybrion.com Davy Brion

    @Laila

    If management ignores the advice, they’re going to have to live with the consequences sooner or later. Whether they want to or not. I’d look for a job with better management.

  • http://www.noctovis.net/blog Laila

    @Davy: “If management ignores the advice, they’re going to have to live with the consequences sooner or later. Whether they want to or not.” => I was thinking, can you live with that? Then I read the last line of your comment :)

  • http://sharpcontents.blogspot.com Ahmad Sheikh

    Yet i didn’t read you article but after having the name of article i m writing that me is agree on this point to some extent.

  • http://www.tensailabs.com/ Gregory Kornblum

    Sadly I have been working with small groups of developers and deadlines that are 10% of the actual time it would take to do it right for almost 15 years. It pains me to write the way I have had to yet at the same time I have grown to write better code faster. It’s just the community does not make it any easier on me. Even with amazing IDEs now I should consider following design patterns and more specifically use the ones that make writing tests easier, tests that are also code. It’s a friggin’ joke. People say but if you do so you can end up having to write less code. Maybe if you have the architectural time but there are people like me who just can’t keep up with the crap people are feeding CIOs/CTOs nowadays. Yet I still try to do all this within the same tight deadlines, troubleshooting issues that only boil down to incorrect usage, etc…

    But I will say one thing, I will take this over working for some public, fortune 500 company who will lay you off to keep stock prices from falling. I’ve made it through the “dot com callapse” and I am making it in the current “credit crunch” as we are still hiring, not firing. So if I am forced to write bad code to make sure my family is well off and stable so be it.

  • Eric

    @Gregory

    I work in a shop with tight, often to the point of being unrealistic, deadlines as well. We struggle with it and certainly have to make pragmatic decisions.
    The old adages of avoiding gold plating and total cost of ownership aside, I am often struck with the dilemma: could I actually have written that code faster with a test? And how would I measure that?

    I’ve worked on projects that I have been proud of in terms of quality as well. The ivory tower preaches that you can go faster in the long run with tests. I question the amount of test coverage that actually gives you optimal productivity for a given project. Different approaches to testing have more payoff and less maintenance cost than others in many situations. This is something to be aware of when reading about testing dogma. 100% code coverage done the wrong way can be an absolute nightmare.

    Sometimes I edit and pray. Most of the time I write at least some tests no matter the time pressure. It is amazing how much time you can waste doing repetitive tasks…

    Testingly yours,
    With that important grain of salt,
    Eric

  • Pingback: Acai Berry Select reviews