# Choose Boring Technology
A blog post from 2015 which made some rounds back then around HackerNews and keeps regularly resurfacing. I guess this is either obvious, or at leat familiar stuff to anybody long enough in the business to keep a couple of project corpses in the attic together with the corresponding deep scars on one's engineering soul.
https://mcfunley.com/choose-boring-technology
and
http://boringtechnology.club/
_"Boring is good. Pick where you chase shiny uplands carefully."_
I internalised this over the years deeply. And I think it paid off well so far. Engaging in a deep/hi-tech endeavour, one needs to focus their energy on that one difficult thing you want/need to do and keep the rest preferrably out of the way. _Boring is difficult enough_, no need to make one's life harder than it is.
And of course the uncertainty:
> The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.
The metaphor of a very limited number of innovation tokens is very useful.
> 1. Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while.
> 2. Adding technology to your company comes with a cost.
> 3. Choose New Technology, Sometimes.
# Make Boring Plans
https://skamille.medium.com/make-boring-plans-9438ce5cb053
A recent blog post continuing the trope of _boring is good_. This time it moves a bit away from technology into team management and tech team processes. I like this shift, it well complements the [choose boring technology piece](https://qoto.org/@FailForward/105618393533273455).
## Novel Technology Deserves Boring Plans
> When we don’t attend to the boring parts by making our plans predictable, the interesting parts turn into extra stress on top of the overwhelming anxiety of juggling these moves.
1. turn vision into boring plans
2. start small
3. execute a change; observe; make notes; learn
7. iterate
## A Strategic Plan Is Obvious and Simple, Even Boring
> Good strategy provides the clarity that enables boring plans.
> Your teams need more than a clear idea of the end state and the hope that smart engineers will inevitably get you there. Plans that are formed around hope are failing plans; hope is not a plan. Plans that change constantly are failing plans. When your plans are constantly changing, it is a sign that you either are making plans that express a certainty you don’t have, or you haven’t done your research to get the right certainty in place. Either of these is a waste of time and an unnecessary stress on the team.
Yes, of course.
Now there's something to add. Once upon a time when I was a junior high-flying and invincible programmer, I would spend nights coding and debugging some project shortly before the deadline, just to beat it into submission and drag it kicking and screaming to the delivery. Proud I was. And so were my managers. I do not know whether they considered it right, or not back then, we all felt somewhat powerless in the face of the unknowns we faced developing something nobody attempted before (because such is the nature of fun projects, right?) and at the same time proud of what we achieved.
Fast forward about one and a half decade later, as a lead of a severly understaffed and underfunded team delivering yet another _interesting_ project (read: with a lot of uncertainty in feasibility and execution). Before the dealdine where you just feel to be a step from everything falling in place and yet everything starts breaking down, my team worked hard a few evenings and nights to beat the project into submission. We of course made it. Then, a couple of days later I apologised to the whole team for all of that and promised to myself never to get into such a situation again (which is of course a fallacy, but one needs to have ambitions, right?).
Apology from a tech lead, or a manager is in order in such a situation, because such situation should never have happened. Because _boring is good_ dictates that to be on time, we shall have worked 9-to-5 and have all the integration and validation test done 2 weeks before the deadline. And we didn't. Because the planning failed. Because the project was not planned to be boring enough.
Keeping learning...
In contrast to
> May you live in interesting times
> -- [Chinese curse (allegedly)](https://en.m.wikipedia.org/wiki/May_you_live_in_interesting_times)