I’ve just finished reading the article “Programming is not Craftsmanship” and couldn’t help but share my own views on this topic. If you haven’t read the article, I urge you to do so right away.
I agree with the author’s view in summary. As a programmer, you may take pride in your knowledge and skills, but the hard truth is the real world hardly distinguishes you from a plumber(may be a more literate plumber, if I dare say). They don’t care if the pipes are laid out in an elegant manner, or not, as long as the water is running. They focus on results, neither the process nor the tools. I’ve tried to share this point of view in the feedback section of every “Why programming language X rocks and Y sucks” blog post I’ve encountered.
But let’s consider the hypothetical situation where you are an entrepreneur, who has an idea of an amazing software. You hire some smart engineers. They build it out and the sales guys close deals. Customers are satisfied, and they ask for more features. The programmers code some more, you bill your customers for their work. Everyone’s happy.
Now a few years later, you’re techies are bored. They are looking for new challenges, as any good hacker would do. You recruit some smart guys to take over their work. They enter a painful transition period. The greenhorns have to learn the intricate details of your feature bloated software their predecessors have built; so they can fix, change or add stuff as demanded by the customers.
And here’s where the architecture of the software comes into play. If your early programmers have laid out a solid groundwork, keeping in mind the readability of the code and the extensibility of the software itself, the new guys will have less of a hard time getting things done. On the other hand, if the programmers have never cared about those things, and just produced code to meet the deadlines, the new guys will go through hell figuring out which part of the software does what and how do they all come together. You’re customers are still waiting for those bugs to be fixed, those features to be added. They get impatient at the delay, and displeased at the higher than usual billing hours upon delivery. At this point you may think having a good “Documentation” helps, but it hardly does. If the programmers never had the time or will to build the software right, odds are against the fact that would have so for documenting it.
I’ve seen(and am continuing to see) it happen. Management and customers were happy playing with the pretty UI. But when I popped the hood out of curiosity, I was surprised(to say the least) to see, along with other things, the spiderweb-like intricacies of the if-else branches, and left with sympathy for the poor soul who would have to ‘maintain’ this codebase(praying that I wouldn’t be the one).
I’ll draw my conclusion with the personal opinion, that a successful programmer(or product manager) knows how to strike a balance between the two extremes. Being the prima donna programmer who whines about the elegance of code should be discouraged by all means. But the coder who pays the slightest attention to quality, must be avoided. For a software shop whose sole business plan is to “build, ship and forget”, the later breed may prove profitable. But not for the enterprise who seeks to deliver innovative and useful products.
(Joel Spolsky, one of my favorite bloggers, gave a presentation on a similar topic. You can watch it here.)