How many times have you been in a meeting where someone on the team says, “And we should make this configurable; just in case we need it”, or “this will scale better if we do x“.
Yea, that about sums it up.
As much as we hate to admit it, we can’t predict the future. Outside of the highly trained epidemiologists, the wider world didn’t anticipate that COVID-19 would have the effect its had. Almost none of us would have predicted we’d be at home for at least two weeks, or that schools would be shut down for the rest of the year, or that toilet paper would be the hottest commodity on the planet.
Let’s say you had some inside knowledge in January and your epidemiologist friend had told you that COVID-19 would be bad, and you trusted that person. Would you have stocked up on toilet paper? Would you have told your teachers and your schools that they needed to make sure their distance learning plans were set?
Probably not — even if we can see the first order effects well, it’s those second and third-order effects that get us, every time.
The mistake we make in building software is that we try to predict those second and third-order effects. We try to anticipate where events are heading, or the effect that each feature will have, and we suck at it.
Slack is currently rolling out their new UI. This is a platform that’s seen a skyrocketing increase in usage due to the Stay-at-home orders; and they’re also in the middle of a (prior planned) UI change. My experience tells me this is a bad idea and will result in lots of pain and an ultimate partial or full reversal, but should you want to believe me, see my last paragraph.
As I said, it’s easy for us to make predictions, but it’s hard to see the future.
So why do we do it?
For one thing, it feels good to feel like you ‘got it right’. It’s proof that you are smart. Now it’s utterly silly for us to hang our hats on this notion, but we do it, all the time, with all the attendant pains it brings.
Contrast this with building software through Test Driven Development, where you never try to predict the future. You just do the next right thing, and the next right thing, and so on, until you have gotten to the point where you can attempt larger changes, because you know there are tests protecting you from making an oops.
It’s a completely different way of thinking about software; and while it doesn’t forgo designing up front; it does minimize the dangers of trying to future proof before you have a clear understanding of what that means, and what the effects are.
In your next design meeting, even if you aren’t practicing TDD, try this out. Try to focus on the next right thing. Or as Einstein once said, “I never think of the future. It comes soon enough.”