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.
3 comments:
There's always the risk of just having a poor programmer, which no technology will ever prevent.
But putting that risk aside, I think the bigger problem with code quality stems from the fact that technology is always changing.
It's almost expected that the code you write the first time around will suck.
Since new constructs (even class libraries) are 'released' every few years, developers are always in uncharted territory.
I first started in C/C++ and my code was pretty crappy. If I were to write something today in C++, I'm pretty confident it would be decent code. Heck, if I had to write something in .NET 2.0, it would probably be decent. However, the code would be constrained to what is available for that language and libraries.
Now if I were to write something in LINQ or WF (.NET 3.0), it's probably not going to be the best code.
Lots of tech pundits always talk of exponential improvements in software development tools and languages, but I wonder if it will ever taper off (i.e. sigmoidal curves vs. exponential). If it does plateau, then we might have a level of stability and predictablity in software design, if not, then I think we'll always be plagued with this cycle of poor code.
Thanks Tom,
You're comments bring up how multi-dimensional this issue is.
You've got two points here, both of which are entirely under your control.
The first is people. If you've got a poor programmer, mentor them so they don't write poor code, or get them off your team ASAP. Your project/team is doomed if you have people that aren't capable of creating great code.
The second is a perfect example of what Steve McConnell highlights early in Code Complete. What you're describing is the "Technology Wave", and being on early side of it. He has an important quote in that portion of the book:
"Programmers who program "in" a language limit their thoughts to constructs that the language directly supports. If the language tools are primitive, the programmer's thoughts will also be primitive.
Programmers who program "into" a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language."
Taking time to learn how to express what you want with the language, despite how primitive it is, will ultimately produce good code.
I know this sounds pretty utopian, and we know each other, we've worked together, and we know how time is at a premium.
But, if you don't have the time, you might want to re-consider being on the early part of the "Technology Wave", and do it in C++ or C# 2.0 and hold off on C# 3.0 until you have time to do it right.
Thanks Tom
My questions weren't specific to any particular technology or to me personally, but rather to point out that each time a new technology is released, there is a lag time before software gets better for that technology.
By then, another technology is on the horizon and we start all over again.
I personally which we all had more time to think about design, but...
Post a Comment