I’m leaping into a lengthy discussion, so I’ll start with the links: Steve Smith wrote this post discussing the craftmanship vs. pragmatism. Corey Haines wrote this response defending the craft movement. And Steve responded again with this real world example. Disclaimer: I know both Steve Smith and Corey Haines, and I have a lot of respect for both of them. There are times when I believe we get off-track by using the wrong words, and the wrong analogies. Or, we point to the wrong evidence from the analogies. Corey made the analogy between software and furniture: craftsmen are like the Amish craftsmen, and industrial software developers are like IKEA factories. OK, that’s a reasonable start, and it points us to the wrong root diagnosis. Instead, let’s look at craftsmen in the construction industry and watch everything they do. I believe Corey’s analogy only examined the finished product. A brief side trip to real home renovations A few years ago we put an addition on our house. A portion of the house was one story, and a portion was two stories. We built above the portion that was single story and added two bedrooms. The final product is high quality, and my wife and I were very happy with the additions. During the process, the carpenters built and destroyed several bits of scaffolding to make their lives easier. The first task was to remove the old sections of roofing on the one story portion. Some of that contained beams that were holding up the roof on the two story section. It was weeks until all the framing would be done, but something had to be added to hold up the roof. One carpenter spent a half hour putting up some temporary beams. The roof stayed up. This kind of temporary scaffolding was repeated several times through the process. One of the last tasks was to cut the doors from the existing second story into the addition. Before that was done, the carpenters built temporary steps to get up into the new section. This needed to last a month or so. Temporary planks were laid while the framing was being constructed, before the final floor was laid. None of these temporary tasks had the same quality that was evident in the finished product. That goes for both ‘finish features’ and engineering quality. For example, the temporary supports for the second story roof would not have withstood sustained 50 mph winds coming from the east. A real risk, but small. In every case, the temporary solution was removed as work progressed to create the real solution. Okay, but that’s not software I believe there is an important analogy for software. The temporary scaffolding is analogous to technical debt. There are times when speed is more important than perfect craft. However, when that happens, you’ll incur technical debt. Steve McConnell has an old post about Technical Debt that’s very pertinent here. In it, he separates technical debt on a number of variables. Unintentional debt, which you incur due to low quality work is always bad. That’s what Corey is protesting against. It’s insidious because you don’t even realize you’ve incurred unintentional debt. Steve Smith is talking more about intentional debt. Here, Steve McConnell points out the difference between long-term and short-term debt: long term is strategic, and short term is tactical. Further, he describes two kinds of short term debt: ‘large chunks’ and ‘small shortcuts’. The large chunks, because of their size, have more scrutiny, and require more justification. The ‘small shortcuts’ are the kinds of quick shortcuts you do when you’re not being careful: not following your own conventions. The purpose of this discussion on technical debt is that debt must eventually be retired. The more debt you take on (of any kind), the more cost to retire that debt. Sometimes even large debt is smart: few of us would own a home without some form of mortgage. That kind of debt is like what Smith (using last names to distinguish between Steve Smith and Steve McConnell) is discussing in his second post. The company’s very existence depends on a short release cycle. In those cases, it’s wise to take on a manageable amount of technical debt. Focusing on the technical debt (as opposed to craft vs. pragmatism) gets you to look at the issue in a different way. No debt is always the goal; I wish I didn’t have a mortgage payment. But, smart debt is wise (I’m glad my last several years of mortgage payments have been building equity, rather than saving the full cost before buying a house. That’s true even in today’s economy). But, if you take on debt, you must pay it off. You must plan part of the budget for debt servicing. Time for the big finish Going back to the house renovation project, I didn’t like the appearance of the temporary scaffolding. It looked shoddy. But, I knew it was temporary, and it was the best plan to achieve the final goal. The true craftsman knows when the first effort must be the best, and when the best plan is to make a (temporary) less than optimal choice, incur the debt, and pay it off. To do that properly requires a frank and honest discussion on the tradeoffs, with a real commitment to paying off whatever technical debt is incurred in the process. I think too many people espousing the software craftsman mantra have been burned by too many companies that incur technical debt, and refuse to pay it off until it threatens the company’s very existence. I know I’ve been involved in failed ‘legacy’ projects where the entire team couldn’t pay off the incurred debt. That memory colors your goals, and your trust with those leaders that push ‘the business goals’. Incurring technical debt (intentionally) is not the same as low-quality work. Advocating against technical debt is not dogma. It’s only when the people asking to incur technical debt and the people advocating against it don’t have a frank discussion on the benefits and costs (both long term and short term) of the decision.  | 
