[Reading time: 1 minute 45 seconds]
Eh, why care about trust?
Trust is just an emotion, but we’re in the very un-emotional, objective business of building software – aren’t we?
Whatever the development process, you’ll shake out the bugs during testing. Easy.
Be honest: that has never worked.
“After development” is way too late in the game to make meaningful changes. At that point, you’re completely committed.
To me, doing things this way always reeked of an organisation that didn’t trust itself. Everything goes according to plan (yeah right) until the very end, and then you just shake the bugs out and ship.
Most people, I wager, have first-hand experience that it rarely works this way.
So why do we keep doing it this way?
I think it’s because people don’t trust their own development process, and so they go for the simplest, most predictable process they can think of.
Even if it’s bad, it’s at least predictably bad.
But it will turn out consistently mediocre (if you’re lucky) products.
Because if you want to actually create good stuff, you need to trust the way you make that stuff.
This has huge ramifications, that all come down to being intentional: actually looking at how you’re creating products (and I promise, there will be things you don’t like – but that’s OK).
You need to have a high-quality development process to build high-quality software.
You need to feel you can trust it.
That it will guide you, tell you where to go.
That it will protect you, even if (especially if) you’re being audacious.
That it will allow you to move fast, try stuff out, but alert you if you go too fast or the wrong way.
Almost like a well-balanced race car: it’ll allow you to explore the boundaries, mile-markers whooshing past in a blur, but warn you in time as you reach your limits – and allow you to regain traction if you find yourself going sideways unexpectedly.