It is a truth universally acknowledged, that engineering orgs—like
greyhounds, sports cars, and wide receivers—slow down as they age.
Odds are good that you have experienced this phenomenon personally at
some point in your engineering career. The slowdown was gradual,
frustrating, and oddly stubborn. It survived: numerous rounds of
hiring; a spate of offsites where inspiring speakers harangued
everyone to “cut through the crap” and just “get shit done”; a
blood-spattered re-org or two; and even a few ground-up rewrites that
utterly failed to deliver on their promised boost in velocity.
If you’re now involved with engineering leadership in some capacity,
you may well have accepted the slowdown as a sad universal truth.
Accordingly, you may have shifted your efforts from the impossible
task of making the org go faster to the thankless but crucial job of
jealously guarding how engineers spend their time—because as it takes
longer and longer to get even simple features out the door, those
engineering hours become increasingly precious.
If all this sounds familiar, I have good news and bad news for you.
In Coding, Fast and Slow, I talked about one of the deepest challenges involved in writing software: the near-total inability of developers to predict how long a project will take.
Fortunately, as that post mentioned, I believe there is a way to work, where the software you write ends up being valuable, and the business people you work with end up being happy. And, critically, this way of working does not involve committing to estimates of how long work will take (which is good, because, personally, I suck beyond all belief at such estimates… even for work which I initially believe will take no longer than a single day).
In a lot of ways, this is The Most Important Thing I’ve learned in my (let’s just say many) years of being paid to write software for people.
The core idea is: put uncertainty and risk at the center of a conversation between the developers and the rest of the business (instead of everyone pretending such nasty things don’t exist). Doing so allows the entire business to tackle those genuine challenges together.
To show what such a conversation might look like, I’m going to develop this approach in detail, in the context of a story.
Earlier this year we at Hut 8 Labs were working onsite with a client
who didn’t have their own code review system. Since a life without
code reviews just isn’t worth living for us, we found ourselves
emailing diffs back and forth to each other, with messages like “about
halfway through the diff you do X, maybe you should do Y?” Eventually
we even started inserting comments right in the attached diffs
themselves—comments like “EWJ RENAME THIS VARIABLE OR DIE IN A
FIRE!!!”—which worked surprisingly well, except that:
it was easy to miss comments and replies in large diffs, even when
the comments were all caps and followed by multiple exclamation points
it was a pain to co-ordinate reviews and replies from even two other people
it was a pain to track down the actual source lines a comment
referred to, which meant an unpleasantly high activation energy for
applying small fixes and suggestions
So we created diffscuss—a code review format based on unified diffs,
with editor support for threaded inline comments, basic review
management and git integration, and (best of all) support for jumping
right from a comment to the local source it addresses, without ever
leaving the comfort of Emacs (or, because Hut 8’s own Matt Papi is a
We’ve been using diffscuss for about 6 months now, and we’ve been
happy enough with it that we figure it’s time to share it with the world.
Check it out at Github or
read on for an example of diffscuss in action.