A common misconception about aesthetics in software
In case you hadn’t noticed: I’m a programmer at heart 😉
Like many or most of my fellow programmers, I’m endowed both with OCD (but only ever so slightly as not to make me dysfunctional…) and a sort of built-in sense of beauty, of “doing things the right way”, when it comes to programming. Chances are that if you’re reading this, you know perfectly well what I’m talking about. It’s that nagging feeling that Separation of Concerns isn’t really observed, that a necessary Refactoring has only been abandoned (temporarily -one can always dream, can’t he/she?) in the face of short-term managerial thinking and that things have not yet been “set right” -a situation that obviously needs correcting. Unfortunately, this type of beauty is hard to make quantifiable, which lends programming a bit of an “art edge” which probably doesn’t sit well with types more interested with things like burn rate, delivered features/solved bugs and such.
The common misconception with managerial types is that this sense of beauty is totally irrelevant or even harmless to the project. Well, it’s not…
It’s both an indication of the craftsmanship (or craftswomanship) of the developer talking about it, as well as an indication of an impending problem (or the presence of technical debt, as you might call it). When a developer says something like “We should have implemented this using the Strategy Pattern.” it’s not the equivalent of “We should have hung this picture frame on the wall using wire instead of a nail.” for interior decoration. It’s the equivalent of saying “We just knocked a hole in the supporting wall. It’ll hold for now, but the wall needs strengthening and will collapse once you knock another hole into it.”. Dismissing him/her means that you’re both throwing caution in the wind as well as that you’re effectively disrespecting your developer and he/she will remember when you ask him/her to work overtime on that particularly nasty bug that crops a few months later after someone knocked another hole in that wall.
(For those of you who think that you have a Process in place for this: in my experience, having a process typically means that people shut off their brains regarding anything governed by that process. Process should be about achieving the common goal, ensuring productivity and providing safety nets, not about placing blame.)
Not listening to your developer having this sense of beauty can and will hurt your project. The bigger issue is that, from a managerial viewpoint, there’s a focus on delivering functional features. Most of the time, a developer’s sense of aesthetics doesn’t concern functionality but rather the infrastructure and architecture of the code -the look-and-feel of the code, but not so much what the code’s actually doing for the business. So, spending time on improving that will have no or no discernible effect on the number of features delivered and will not provide any business value in the near future. Again, the analogy with building a house is useful: the family will want to live in the house as soon as possible, even while it’s still under construction. Given that, having furniture and drapes seems much more important for the end users (the occupants) than having a construction which allows expansion in a few years’ time, even though some walls are creaking under stress somewhat… But, there’s a time that that expansion will be required or that those walls are cracking or even collapsing. At that point, you’ll remember that worker’s warning.
There’s another side to my message: developers should voice their opinions more clearly and loudly and should stand up more to the powers-that-be. When a project manager asks me for an estimate and says “It’s too much. You should be able to do it in half the time, if you just employ these-and-these hacks”, my response simply is: “If you don’t like the estimate, please find some other chap to do your work and don’t call when this person’s work falls apart (unless you’re willing to take me up on the original estimate, of course).”. On one occasion, I’ve simply refused to provide an estimate for doing something the wrong/hacky way, while I was willing to put a number to the right way, which was much more risky but reduced technical debt considerably. In the end, I both proved to be right as well as earned some extra kudos for using my skills in this way for the benefit of the project.
By the way: there’s a very nice article by Jeff Ello about managing geeks.