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.