
Shims, Jigs and Other Woodworking Concepts to Conquer Technical Debt - zt
http://firstround.com/review/shims-jigs-and-other-woodworking-concepts-to-conquer-technical-debt/
======
nissimk
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.

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.

~~~
eric_h
I've always found unit testing to be the best way to test drive small units of
code, and integration tests the best way to find and prevent regressions in
the integration of those units.

My workflow over the last few years has been test drive a unit, plug it into
the application, write an integration spec.

~~~
twic
Have you tried writing the integration spec first?

My workflow is to start with the coarsest-granularity, most outside-in test i
can. The nice thing about those tests is that you can write them based on the
requirements, without thinking about implementation much, and then directly
see what implications they have for implementation. Whereas if you start with
fine-grained tests, you only discover the constraints that the requirement
imposes on the implementation when you bump up against them halfway through
development.

~~~
eric_h
I was intentionally brief in describing my workflow, obviously different
features require different flows. If the integration test can be covered by
simple requests specs for the api, then I will write that first. If, however,
the feature requires a bunch of pointy-clicky feature tests, then I will write
the integration tests afterwards (I do a lot of single page web apps, so
pointy-clicky specs can be important, but are too slow to test drive with).

[Edit: of course this is still a gross generalization, none if this is a hard
and fast rule]

------
twic
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.

Mix in master carpenters = Coaching (kind of - this is an interesting blind
spot in the classical XP literature)

Measure twice, cut once = Simple Design and Pair Programming

Collect and codify your standards = Coding Standards

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

Build modularly = (one of the goals of) Refactoring

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.

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:

[http://c2.com/xp/ArmCl.html](http://c2.com/xp/ArmCl.html)

------
spinlock
> 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.

This kind of crazy, out-side-of-the-box thinking is exactly why we need more
women in computing.

------
jessaustin
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.

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.

