I’m working on a series of posts that outline a book’s worth of suggested curriculum on how to learn some of the technical practices that Agile Programming involves. The first post is here.

The Myth of Affordable Technical Debt

Along the way, I’ve re-discovered that too, too many software professionals still misunderstand, fundamentally, what Agile Programming and Software Craftsmanship are about, and why we bother with them. So I’m summarizing my view on that here. I’m not recapitulating the history now (later, perhaps). I’m just trying to gently make the case that sufficient long-term quality is something we can never not-afford.

In the heat of the production pressure to get a User Story out the door by hook or by crook, the discussion about “how much craftsmanship can we afford here” does keep arising (with the best intentions on all sides, no doubt). That’s my context for how and why programmers should learn deep craft. I suggest that almost no-one in software is ready to ask that question.

By Agile Programming, I Do Mean Computer Programming

My definition of Agile Programming is computer programming done at a high level of craft. (Note that in this series of posts, I am not talking about the entire superset of Agile Software Development practices and principles, some of which are technical, and some of which are not.)

Another definition of Agile Programming is Clean Code. These are ways to think about what it is. But why do we do it? It really is all about the smoothest flow of value through the code and the team. It is about highest ROI, and lowest TCO. Put another way:

Any programming practice or choice that does not make or save money for someone, somewhere, someday is not agile, and is not software craftsmanship.

Truly: Why Do we Bother? Are we Being Quality Fanatics?

We are not being fanatics. We are avoiding lots and lots of pain.

To a new regular-army combatant fresh to Guadalcanal in 1942, it may appear that the combat-veteran marines are completely obsessive-compulsive about cleaning their weapons. That’s because those fresh arrivals have not had their weapons jam frequently enough in heated enough battle in a nasty jungle. Field stripping a weapon in a way that appears obsessive and fanatic is just pain prevention. Pure and simple.

The idea of the high software craft inherent in true Agile Programming is to provide exactly, and only, the highest short-term ROI and long-term ROI, and the lowest short-term and long-term TCO for a codebase as simply another asset to be managed (around which, for example,  CAPEX and OPEX expenditures must be carefully predicted and managed these days).

Too frequently, we are asked to build straw houses when only brick houses will do, and we have no way of making it clear how false an economy this is. In a comment thread on a great blog post of a friend of mine’s, the debate rages about, essentially, the economics of Clean Code (“CC”) versus Quick and Dirty (“QD”).

Two things: I have frequently found that the advocates of QD have not bothered to learn CC deeply. They are arguing from at least partial ignorance and fear. (That is not true, BTW, of Naresh Jain, who is a very advanced Agile Programmer.) If you really are as good at Agile Programming as Josh Kerievsky, or Ron Jeffries, or Mike Hill, or Naresh Jain, then yeah, I’m willing to have User-Story-specific discussions about specific short-term “speed vs quality” tradeoffs. Otherwise, I’m not willing to have that discussion with you. All these guys have spent more than 10,000 hours test-driving. Once you’ve done that, let’s talk about CC vs QD again.

Only if you are deeply, deeply expert at test-driving clean code does it make sense for you to talk about breaking the rules. Only then do you have a feel, and deep knowledge about, the rules for breaking the rules.

The other thing is that QD experts (the Duct-Tape Programmer) are not taking long-term ROI and TCO into account fully enough. Yes, I want to ship product as regularly and quickly as I possibly can, with least thumb-twiddling. But no, I don’t want an asset in my portfolio made of duct tape and WD40. What’s the duty cycle on that thing? One release? Two?

The QD experts are arguing that QD works for a User Story, or an Iteration, or a Release. Well, yeah, you can have a roof over your head faster if you build with straw. So what? Is that a way of saying “I don’t believe in storms.” ? In the specific context of getting good-enough releases out the door for startup ventures, are we making it clear enough when we are distinguishing between prototypes designed to win investment capital, and production code designed to live for 25 releases?

The questions “How much craftsmanship can we afford for this Iteration? or this Release? or this User Story?”,  when asked about anything but spikes or prototypes, are nearly always premised in false economy.

As my friend Dave LeBlanc says: Later == Never. You will never be able to “Refactor” your straw house into a brick house. It will need to be rebuilt from scratch, eventually. Factor this into your ROI and TCO estimates. Oh, again, in the context of CC vs QD for startups, there is another sad corollary I’ve seen borne out time after time:

Every prototype ships, and becomes long-term production code. Especially for boot-strapped startups, whose investors will not agree to purchase or fund prototypes.

High software craft, Agile Programming, are not knob polishing, or gold plating. Agile Programming is about getting it right the first time, and getting it right over and over again. It is about optimizing the long-term return on an investment.

How come our codebases cannot last as long as our best cars? Why do most codebases that have not exhausted their business value end up going through expensive, dangerous rewrites?  Aren’t these rewrites fundamentally avoidable? You bet they are.

The fundamental unit of waste in software development is also the fundamental unit of denial: the gigantic codebase rewrite.

We can do much, much better than that. That’s what Agile Programming and software craft is about.

This level of dedication to quality is very much like Honda dedication to quality. It’s not about burlwood on the dashboard, or spoilers on the trunk, or pinstripes down the sides (though if you want those in the GUI, we can do that too, as in an Infiniti). It’s about a 300,000-mile-duty-cycle drivetrain, come hell or high water. It’s about the industry growing out of its addiction to rewriting business-valuable codebases after a few releases, because we can’t work them anymore.

How many 1993 Chevies does anyone in Michigan see out there on the roads, still purring along with few issues? Few. But you know what? There are still lots of 1993 Toyota Camries out there on these snowy, badly-maintained roads. Until recently I drove one every day (and I still own it as a spare-loaner-beater). It’s a little dinged up. And the AC just gave out (after 18 years!). But it also still starts in 6 degree weather, and runs smooth at 80mph, and gets 30mpg. Because those Camries were made with highest long-term ROI and lowest long-term TCO in mind.

So, throughout the series of “How To” posts, please keep this definition of the what and why of Agile Programming in mind.