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.