“You can tune a piano,” goes the old joke, “but you can’t tuna fish.” I’ve
come to believe that you can’t really tune the automated alerts you get from
your monitoring systems either—at least in the sense that we usually mean when
we complain that “our email alerts are out of control and need to be tuned
properly.” Instead we should be spending our time and attention tuning a
larger, more complex system—of which alerts are just one part.
Read more…
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.
Read more…
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.
Read more…
Subscribe
Subscribe to our e-mail newsletter to receive updates and new articles.
Or, add our
Atom feed
to your favorite reader.
