Recently Jeff Atwood had a post arguing that the important part of software is not what your code looks like, it's that your application works. It makes no difference to the customer whether or not you have a 1000 line method or alphabet soup variable names or a high Cyclomatic Complexity. In his words:
Sure, we programmers are paid to care what the code looks like. We worry about the guts of our applications. It's our job. We want to write code in friendly, modern languages that make our work easier and less error-prone. We'd love any opportunity to geek out and rewrite everything in the newest, sexiest possible language. It's all perfectly natural.
The next time you're knee deep in arcane language geekery, remember this: nobody cares what your code looks like. Except for us programmers. Yes, well-factored code written in a modern language is a laudable goal. But perhaps we should also focus a bit more on things the customer will see and care about, and less on the things they never will.
Ultimately this is true, until the result of that code either:
- Causes the software not to work.
- Increases the cost of the software.
At that point the customer really starts to care. Now, Jeff's post in specific is talking about open source projects, in which case, the possible increased cost of the software takes on a slightly different meaning, but it's still an issue.
I think this risk is what the programmers understand. They understand that crappy code, and making decisions (at the bits and bytes level) that ultimately don't benefit the customer in the lo are a bad idea.
A good example of this is the recent news that IE passed the ACID2 test. Does the customer care about the ACID2 test? Not most. Most sites will work in both IE and FF, mostly at the expense of developers and the crappy code they had to write to produce that compatibility. Most people browsing could care less about the proper way to render a block element or to apply padding or margins to a span tag through CSS.
The developers understand that bad code costs the customers more in the long run, and support of not writing ugly, nasty code is something that the customer cares about (but they just don't know it).
Now, I'm sure that Jeff, if anybody, knows this, and he might be talking from the perspective of "our code sucks, let's rewrite the entire thing", which I have some other thoughts about (another post, another time). I can say though, without any doubt, that just because your customers don't care what your code doesn't mean you should write poor code, or brush crappy code under the rug when you are in it.