Tech Debt Reaction

I am still decompressing from the tech debt workshop. It was an exhausting but awesome two days.

Right now, I've got the day job to do, plus lots of video editing, thank-you notes, and follow up work. But here's a quick few things that came up:

* Ignorance I've come to separate bad code written through ignorance from bad code written when we knew better but felt pressure. The former is fixed by better hiring (and maybe salary) practices. The latter is what I am interested in when I speak of tech debt.

* Bug Fixin' One of the strong arguments of the workshop was "always, always" fix bugs as soon as you discover them. I'm not convinced this is true 100% of the time, but it's true often enough that the cavalier attitude towards bugs I often take, well, bugs me a little.

* Moral Hazard This happens when the person doing the work (dev) is separated from the end customer by too many layers. In this case, it's possible for the tech staff to be rewarded in the short term for velocity at the expense of goodness. The solution is to bring the customer into the conversation. At Socialtext, the Customer-Proxy is the Product Owner, and I believe we do a decent job of this, but I've been spending more and more time on customer-facing calls - and I think thinks is a good thing.

* Impedance Mismatch Chris McMahon started this conversation on his blog and with a lightning talk. His simple example is a log file parser. Hire an intern to do the work and he will miss key things; hire a genius senior dev who feels the work is beneath him and you'll get something over-engineered, gold-plated, that tomorrows junior dev might not be able to read. Two solutions: Increase your hiring rigor, or, more likely, scale the work to fit the ability of the person doing it by breaking the work up into much small tasks for the intern.

* Liquid Assests Tech Debt is a pretty negative metaphor; it starts out with the assumption that the dev team did a crap job and how do we fix it. But, what if the dev team didn't do a crap job - what if we built a system that was well-organized, with clearly defined objects that had specific purposes? Then we could reuse those objects, and future development could (theoretically) get faster, not slower, over time. For what it's worth, I have experienced this when trying to build test frameworks in perl (or "real" code in C++) at companies that do real domain modeling of objects; you simply instantiate the object and use it.

* Affordances. Building on top of the liquid assets idea is one where the team identifies it's repeat activity and builds technologies to eliminate repetition - such as vi extensions or maybe wikirad. One teach said they spent every Friday working on test infrastructure in order to go faster. I don't know about limiting it to just test infrastructure; I wonder if any kind of dev automation might be a good investment.

Brian Marick also has some follow-ups here and here.

The other interesting thing about the workshop is the financial breakdown. You may recall that this was a zero-profit conference, funded by the Agile Alliance, the Software Division of the American Society for Quality, and the Association for Software Testing. The bottom line is that after food, video cameras, supplies, and helping to cover the expenses of a couple of people who came in from out of town, we still have money left over. (We didn't even have to ask AST for any funds - yet - but we will pull that cord if we need help getting the video editing done.)

Which means I have to send an email to someone at the Agile Alliance and ask them where to send a check for $120.00.

I wonder how often they get an email like that?