I try to avoid doing copy posts (ie where I just parrot someone else's thoughts) but this struck a chord with me today.  Jeff Attwood of Coding Horror fame talks about the value we place on code beauty and how no one else cares.  To quote:

I have a friend who works for an extremely popular open source database company, and he says their code is some of the absolute worst he's ever seen. This particular friend of mine is no stranger to bad code-- he's been in a position to see some horrifically bad codebases. Adoption of this open source database isn't slowing in the least because their codebase happens to be poorly written and difficult to troubleshoot and maintain. Users couldn't care less whether the underlying code is pretty. All they care about is whether or not it works. And it must work-- otherwise, why would all these people all over the world be running their businesses on it?

I couldn't agree more.  It's a pragmatic approach to software development that thinks about delivery and the customer before how pretty the code is (i.e. you should be a developer not a programmer).

That said, just because a code base is crappy doesn't mean you shouldn't try to improve it.

The worst thing about spaghetti code is how hard it is to maintain, how fragile it is, how much effort is needed to add to it, etc.  While the customer cares more than anything that their application works, they will also care that you can incorporate their new requests and ideas without requiring the concerted effort of the entire Indian IT workforce to add them. They'll also want to know that when you add something to the application that you are confident that you won't completely bork the stuff that works today.

Improving a code base takes time, (a lot of) effort and a great deal of attention to detail and retro fitting a code base with unit tests can be tedious, extremely difficult and sometimes very painful (which is why it's typically not done).  But if you don't do it and you leave your code to rot then things will only get worse, morale will fall, people will be lazy and use excuses like "the code was already bad, why try and fix it?" and so forth.  This in turn means that the quality of the system will drop and the customer will go from having working software to patchy software to finding another supplier pretty quickly.

At the end of the day it's a matter of balance.  Yes working software is the only thing us developers should be measured by and focusing too much on "purity of code" is a bad thing, but you shouldn't swing to the other end of the pendulum either and churn out the ugliest thing that works.  One day you (or some other poor soul) will have to change that code and then things will really get ugly.

The Moral? Write good, clean whenever you can but don't polish it until it shines and then try to pass it off as "business value".  And when you do have to work with someone else's legacy code base, no matter how bad it is, don't get frustrated with it, just do what you can to improve it, one line at a time.