Technical Debt Peer Conference
Matt Heusser is having a peer conference. I believe it’s his first.
It’s on the topic of technical debt.
The idea of technical debt seems to be that there are tasks you are free to neglect when building a technical artifact such as software, but if you neglect those tasks, you will incur a sort of “debt” that weighs on you in the form of nagging problems that sap your productivity. Examples include neglecting unit testing, refactoring, reviews, or source control.
March 1st, 2008 at 9:04 pm
James -
Thank you for the mention, and you are correct - it’s the first time I am organizing a peer conference. I suppose a decade-old user’s group, and a 140-person exhibition conference, both of which are still around today, should count for something.
March 3rd, 2008 at 1:29 am
My first reaction was to say that the biggest technical debt I’m familiar with is the kind that crushes a project before the ship date (or mutates it out of all recognition). But, more properly, I would say that that’s usually the sum of a whooole lot of little technical debts that get swept under the attentional rug until they swamp things.
In the case of some celebrated embedded systems, technical debts such as actual reproducibility, design for manufacturability and the de-rigging of demos all loom large in my memory.
For a recent example of too many technical debts to easily count, I submit that Second Life is one good place to look for participants. Matt ought to try connecting with some of the folks at Linden Lab. The installed base and “success story” of SL are fraught with growing pains now, as they try to shift gears into the more-scalable “HetGrid” and much more speedy Mono-based scripting.
Another place that probably has much grist for the mill is Yahoo.
I don’t mean to pick on these folks — I’m pointing out that they have managed to succeed and still might have some people who’d be assets if they attend.
March 6th, 2008 at 6:15 am
James:
Is it right to say that technical debt starts from the point you hire less a competent person for development (we could have hired more competent, but some how to due to cost constrainsts we did so) or not.
[James' Reply: What an interesting way to think about it. Makes a lot of sense to me.]
March 7th, 2008 at 11:32 pm
It makes sense as one explanation, but it holds “competence” out as a scalar when it might very well be a multidimensional vector. The “Peter Principle” did that, too. I get the feeling that one might be locking onto a convenient one-size-fits-all explanation if one takes this model as definitive rather than thought provoking.
One could equally well claim that technical debts will inevitably arise in every project ever undertaken, because humans are fallible and can never model reality with ultimate fidelity. The more audacious the undertaking, the larger the likely technical debt. But how do we measure “audacity”? By the results? Maybe not. Tversky et al tell us we humans are lousy at estimating both the future and the past.
May 2nd, 2008 at 2:39 pm
Debt and interest are facts of life, how they are handled is one of the defining factors of any team or individual.
May 27th, 2008 at 7:03 am
When we say “Technical Debt” we are invoking an analogy, a way of talking about one thing in terms of another. The analogy that we are invoking is that of financial debt. Financial debt is cumulative. Our current debt is the net aggregation of all previous years’ deficits and surpluses.
But sometimes, when we build a technical artifact and we neglect certain tasks, we are merely taking a risk that we can, if we are lucky, get away with.
Consider another analogy. I know that when I go for a ride on my bicycle I should wear a helmet. But sometimes I ride my bike without a helmet. If I complete the trip without incident then the trip is a success and I have not accumulated any “debt”. The next time I take a trip I can wear a helmet and I am at no greater risk because of my current negligence.
Certainly there are tasks in software development that incur a debt that is cumulative, but aren’t there also tasks that we undertake to reduce a risk, which, if we get away with it, we can eliminate, breathe a sigh of relief and feel that we have saved ourselves some time that would have been wasted?
If one makes such decisions consciously, they may well be justified.
June 1st, 2008 at 1:01 am
Sounds to me as if all you’re saying is that most technical debts can be written off. And of course most people agree. In a similar vein, I can’t pay any “technical credit” owed to the folks who tamed fire or developed the wheel-and-axle, no matter how much I might want to.
Let’s do a gedanken, though: what actual technical deficit was present regarding the Y2K bug (in aggregate) in the entire base of installed code, world-wide, in (say) 1996? How much of a difference would we see in the world today if we’d just “eaten it” — if not a single man-second had been spent attempting to address Y2K?
In the above gedanken, are these things even knowable?
Deciding that “‘we’ [got] away with it” is particularly easy in an environment where there is essentially no warranty of merchantability or fitness for software. Cem Kaner has had a fair bit to say about that.
It might take multiple “black swans” for that to change. It might never change. Too soon to tell.
December 4th, 2009 at 1:11 am
Interesting concept. But I think the real question is whether anybody really cares that they have incurred a technical debt. We seem to be rewarding incompetence all the time, by purchasing incomplete software and then one bug fix after another.
Don’t you sometimes just wish that the programmer had done an adequate job to begin with?