A post about software craftmanship (stop me if you think you've heard this one before)

During lunch at a Progressive.Net event a discussion came up on why code more often than not ends up messy and ugly with large maintenance costs as a consequence. Every single developer now a days know about TDD, SOLID, CI, DI, DDD, OOP, XP etc., etc. which are all meant to make our code maintainable, readable, testable, extensible and so on and so forth. Obviously, not many programmers practice these fine principles since there wouldn’t be the massive amount of smelly code out there (just ask 10 of your colleagues what they’ve seen more of, clean code or ugly code or for a quantitative answer look here).

Anyway, the discussion went on about how to enforce the practice of writing clean code and several suggestions were laid forward; practice pair-programming, do TDD, follow boy-scout rule etc. which are all great things and you should use it. However, I believe that these practices are useless unless the programmer has the right attitude, i.e., wants to produce high-quality software. But isn’t that every programmer’s desire? Sadly not. Some programmers “only” do this for a living, not actually interested in building software, let alone well-crafted software and some programmers are more interested in writing code fast but without much concern for the quality. Delivering fast might get them a chance to work on yet another green-field project (you might call this kind a duct tape programmer). Of course, the ones who gets to clean up afterwards aren’t too happy.

Another reason that code ends up ugly even though intentions are the best is time constraints or rather bad planning and project steering. Under pressure it’s very easy to take short cuts and easy turns to get the code working, i.e. skipping unit tests, code reviews and even basic testing just to have something to show the customer in time – let’s take the hit later right? I’ve been there and probably you too. This is alright as long as you try to figure out what went wrong at the review and learn from the mistakes made.

I’m not pointing any fingers though (well maybe just a little but I’m pointing at myself as well so it’s ok), we’re all guilty of writing crappy code, especially when time is short and the customer is screaming for a new delivery on the other side of the fence. My point is just that in the end, it’s the developer’s attitude that decides whether software ends up crappy or awesome.

A relevant question is though; is it always desirable to have clean, well-crafted, code? For example, if the planned lifetime of a product is only a couple of years you might want to prioritize short time to market over quality and maintainability. Or if you’re racing against some competitors you might produce a ‘hack’ as the first version in order to pass the finishing line first, otherwise you might be put out of business.

Some people think that software engineering isn’t actually engineering since there are very few standards, that it is actually more adequate to compare it to gardening than to ‘real’ engineering. You could of course argue that the huge software maintenance costs out there proves this point but I’m not convinced. The Engineers Council for Professional Development has a definition of engineering that a lot of software do not live up to. However, I don’t believe that software intrinsically suck, I think we as software developers suck at making great software. Compared to traditional engineering diciplines like building construction, the construction of software has a lot more degrees of freedom attached to it and therefore it is much easier to screw up. And let’s not forget that our industry is just a baby compared to many of the ‘real’ engineering diciplines and is still in it’s early developing phase.

There are a great deal of really smart people who over the years have spent a lot of time to figure out how to make awesome software. Why not take a part of and apply some of their wisdom in our code?

Whether you want to call it engineering or craftmanship or art for that matter, it all boils down to this: without the right attitude the outcome will always be junk. Having the right attitude, i.e. wanting to create awesome products won’t make it automatically happen, but it will make it possible.


  1. Another interesting question: Is it more expensive to write Clean Code than to write ugly code? For a novice developer I would guess that it is more expensive. But for a seasoned, experienced developer the overhead should be very low. Obviously there are a legacy code and clean up issues to handle but for virgin code the overhead should be extremely low if you know what you are doing.

  2. Christian Jacobsen

    Interesting question indeed. Clean code is hard to define but if you look at TDD at least one study[1] shows that it takes a bit longer to develop your features (~25 % on average) but the decrease in defect count is significant (40-90%). So considering that the largest cost for a feature is the maintainenace the ROI when using TDD should be quite high.
    [1] http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

  3. Great post Christian! I totally agree with you that some (maybe even most) programmers have the wrong attitude. But that is not the whole truth, I have also seen programmers with the right attitude, that really want to produce clean code, but they just keep screwing it up. Threy’re just not competent enough to know what Clean Code is, even though they think they are. Their code are among the hardest to read and understand.

  4. Christian Jacobsen

    This is an area where I think all programmers have a great responsibility to educate, give candid feed-back and to discuss with other programmers about clean code and what it is.
    It might be that not all programmers have the same perception of what clean code is; one programmer might think that implementing the open-close principle using the visitor pattern is obviously clean while another programmer might not understand this code at all.

  5. Milvio Diaz

    There must be a higher cost to writing Ugly code – maintenance, support and client satisfaction. Althought there maybe time constraints, the final cost is probably higher when taking short cuts – do it right, compile it once.

  6. Christian

    @Milvio: so true but the 10k $ question is how do you make it to the right path in the organization?

Leave a Reply