This is a good article. The title says conquer technical debt, but much of the article is about becoming comfortable with the technical debt. In fact, all code is debt. As systems become larger, they are harder to modify and maintain. All of the supposed engineering techniques that prevent this are pseudo science snake oil. I'm sure many engineers would consider the "shims" described in this article to be further technical debt, but they increase agility and are frequently worth the cost.<p>I particularly liked the description of automated tests as jigs. Rather than unit testing small components of code, I've always believed that integrated tests that cover as much of the functional surface as possible are better. Tests for regressions of any bugs that were fixed and a performance / integration test suite can go a long way towards increasing comfort in making changes to complicated systems.
This article reads a bit (if only a little bit) like an attempt to rephrase ancient XP advice (which is itself a selection of truly ancient pre-1997 wisdom) in a refined but folksy way which won't raise hackles.<p>Mix in master carpenters = Coaching (kind of - this is an interesting blind spot in the classical XP literature)<p>Measure twice, cut once = Simple Design and Pair Programming<p>Collect and codify your standards = Coding Standards<p>Scrap the shortcuts that don’t save time = no specific practice, but a foundational idea of XP is that we go faster by maintaining high quality<p>Build modularly = (one of the goals of) Refactoring<p>I think it's quite a good attempt! Metaphors can be very powerful when they fit. Or should i say, when you're able to work with their grain, rather than against it.<p>I'm reminded of an older such effort, ARM/CL, which (jokily) rephrased it in military terms, to make it more palatable to serious grown-up companies who would never contemplate the zany Mountain-Dew-flavoured antics of those 'extreme' weirdos:<p><a href="http://c2.com/xp/ArmCl.html" rel="nofollow">http://c2.com/xp/ArmCl.html</a>
> So, founders, hire beyond your social circle. Look for engineers who have stayed at companies long enough to experience the long term impact of their decisions.<p>This kind of crazy, out-side-of-the-box thinking is exactly why we need more women in computing.
Possibly off-topic: in carpentry, typically one uses a pair of shims rather than one by itself. Since a package of shims are all cut at the same acute angle, a stacked, reverse-oriented pair forms a perfectly flat block, the thickness of which can be adjusted.<p>I'm not sure if that more detailed metaphor means anything about e.g. API versioning. My initial reaction to API versioning is "why do you hate HATEOAS?", but if one were committed to that particular methodology, perhaps it could be made easier by imagining a version shim on both the client and the server side.