I do think the perils of dirty code are often overlooked, especially by management who want a 'quick fix' and feel code quality is vanity.<p>The primary problem with dirty code is that it adds a cognitive tax to the code base - anybody coming to the code base is going to have to invest considerably more effort attempting to unravel the mess than the problem at hand actually demands.<p>The more dirty code grows, the worse it gets, sometimes to the extent that the code base becomes so messy that certain features become prohibitively costly, and the road back is long and arduous.<p>Maintaining clean code (which basically implies constant refactoring) is a lot like brushing your teeth - seems like a hassle at the time, but if you don't do it you're pretty well irreversibly fucked in the long term.<p>Also on this subject - the 'Big Ball of Mud' architecture [anti-]pattern - <a href="http://www.laputan.org/mud/" rel="nofollow">http://www.laputan.org/mud/</a>
<i>4. Dirty code inhibits the formation of an ownership culture.</i><p>I've found quite the opposite. The dirtier the code is, the more you try to keep the same guy on it. You hesitate to commit him to any other projects if there's even a prospect of needing him to work on "his" code. Programmers love that shit, especially the ones who write dirty code. It makes them feel smart, important, and indispensable (which unfortunately they are.) Plus, nobody is going to be looking over their shoulder gasping and saying "no wonder it's always broken!" because nobody else wants to get their brain dirty in that code. If you're a bad coder, taking ownership of your own crappy applications is your ticket to escaping peer review and protecting your job.<p>By contrast, the most vital and hard-core piece of C++ code we have at my company has had contributions from almost half the C++ developers we've employed, thanks to a great initial design and good stewardship. It's nobody's code except whoever is currently hacking on it. That doesn't inhibit people from feeling responsible; the quality of the code inspires everyone to maintain it even though nobody has any real claim to ownership.
I'm dealing with some dirty code now, so this really resonates with me. But I disagree on two points:<p>1) Dirty code has "concepts that don't map to the domain". This is true at one level of abstraction. An Orbitz-like application is going to have objects representing flights and rental cars and hotel rooms. But a couple of levels down, there are highly non-intuitive search algorithms with all sorts of concepts that have no obvious connection to the domain. I think the real point is not to expose low-level abstractions higher up.<p>2) "Dirty code inhibits the formation of an ownership culture". A huge problem with dirty code is that it is permanently owned by the author. No one else can possibly fix or extend it. What you really want is code so transparent that anyone can get into it quickly and easily.
From the guidelines:<p><i>If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."</i>
Thanks, that was interesting. Of course we all (quite possibly instinctively) know the problems with legacy code, and by extension the crippling effect of taking on the "agile / scrum" methodology without the unit testing side of the work. The "pay me later" side of the coin is so much less sexy.<p>The story of IMVU is (I think) even more fascinating. I see your ads all over the place (and therefore assume you're successful) but it really is a case of "who the hell knew <i>THAT</i> would be successful. I mean - IRC with 3D avatars? Brilliant! :) (I oversimplify out of ignorance, not disrespect. I've never used the service, but assume it's very much loved by the target market).<p>Test Driven Development and even just writing unit tests is so much less rewarding, because you can't say "see? look, I've made something new" - in fact - 99+% of the time, they're really just about proving 1+1=2. Who gets excited by writing a test to tell you that the sky is up and apples fall down?<p>It's only a few thousand lines of code in that that kind of validation and reassurance really starts to pay off. Once you get yourself that far into the matrix - you really need someone to tell you which way gravity falls.<p>(Should I have gone with an inception reference instead? blah blah falling top)
<i>6. Dirty code incentivizes the business to invest in tangential revenue work rather than attacking core business problems.</i><p>This is very true, and it's also true that clean code can turn into a core competency in itself. The company I work for got a big competitive advantage by being the best at something that at first seemed tangential to our core competency. We added some features, kept them clean, found it easy to add more, and eventually we had another "core competency" that we never even planned. We had no strategic plan or strategic commitment of resources to develop our capabilities in that area; it only happened because it was so easy to add the features our customers asked for, because the code was clean. (We were also lucky that our early customers asked for the right things, which resulted in us having an attractive suite of features.)
Good insight into the real, startup-relevant costs of technical debt (TLDR: sucky code makes it disproportionately harder to improve or change your product). It's easy to say "we're a startup, we might throw all this code away next month, so time invested into code quality is likely to be wasted", but as this article describes, that's simplistic and short-sighted.<p>This seems to have been written around the same time (Oct 2008) as IMVU started talking about the benefits of continuous deployment (Feb 2009 <a href="http://timothyfitz.wordpress.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/" rel="nofollow">http://timothyfitz.wordpress.com/2009/02/10/continuous-deplo...</a>). I'd be interested to know whether their CD-based development strategy helped to dig them out of the hole they apparently coded themselves into.