Schedule and Events



March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email: Matt.Heusser@gmail.com

Monday, October 22, 2007

Technical Debt II.5 -

I've been struggling for the past two weeks to put up a post on technical debt that doesn't sound like passive-aggressive "how to manage your boss" or "how to trick your boss."

That is not my intent.

So, while I may post one of my working copies later, I'd like to make this clear now.

Imagine a carpenter who is a professional craftsman. The carpenter is brought into a job and told to "hurry it up - we have to have the framing complete by November 1st."

Now, carpentry is more fungible than technical work; if you have a standard pattern, it is much easier to throw a half-dozen extra bodies on it to hit the date. The carpenter brings this up to the general contractor, who says "No. Work unpaid overtime if you have to, but HIT THE DATE!!"

What is the carpenter going to do?

Well, he could slack off a _bit_. He might save five or ten percent of his time by doing a poor job, that would decrease the lifespan of the house substantially.

But as a homeowner, you don't want him to do that, do you?

Moreover, the carpenter probably went though an apprentice program for three or more years, where he saw reasonable standards, and, possibly, heard a journeyman say "no" a couple of times.

If he loses the job, so be it. In most cases, carpentry is contract work, and there are plenty of people looking to build houses. The point is, he is responsible for doing high quality work to an ethical standard. To paraphrase Richard Bach, you can either own your process ... or be it's victim.

We lack and understand of craft in Technical work. The job training programs we have are largely academic, not On The Job Apprenticeships - we don't know how to respond.

So we blame management, take shortcuts we should not, and act like victims.

Shame on us.

Shame on us!

Please keep that spirit in mind when I post the next article in the series. I am still not 100% confident in it. If you know me personally, please feel free to email me and ask for a preview before I post it; I am interested in your opinions.

--heusser

1 comment:

steve poling said...

I think your distraction with managing bosses who would pressure a software guy to incur technical debt is not good. You're taking a Dave Ramsey approach that "any debt is invariably wrong at all times."

Imagine the following scenario: twin brothers graduate from university and one goes to Jedi Co, and the other goes to Vader Works, two identical start-up companies. The first brother righteously ignores his boss, the salesman, the accountant and anyone else who says, "We need to ship something now!" As these contrived examples would have it, Jedi Co. goes bankrupt two weeks before his software is perfect.

Meanwhile, at Vader Works, the other brother has gone over to the dark side, put on his cowboy coder hat and thrown together a steaming pile of ugly code that is utterly unmaintainable, but it shipped on time. Vader Works stays in business and turns a profit.

Now, the second brother regrets going over to the dark side, tosses the Emperor into a conveniently located ventilation shaft, and unlike Anakin Skywalker, he survives the experience to take the helm of Vader Works.

He then proceeds to a funnel portion of the obscene profits his product is throwing off to fund refactoring that steaming pile into something that doesn't suck. Over time he pays his penance and repays all the technical debt he incurred during the start-up phase.

But, you say, he spent more money on development than if he'd "done it right the first time." True. He could not afford to do it right the first time, He could afford to do it fast. Something burdened with technical debt is no less salable in the short-term.

Debt in a business setting is a tool. Just as there are businesses who handle financial debt responsibly, we need technical organizations that handle technical debt responsibly. Just as finance guys clearly understand things like interest rates and compounding frequency, technical debt needs the same kind of characterization to guide decisions that are more enlightened than "just don't do it."