This was originally posted on wpDaily and now resides at Torque Magazine.
I saved up for this chair.
I don’t remember when I first saw a mission styled chair like this one, but the moment I saw it, I knew I wanted it. It looked sturdy (and indeed it’s the only chair in the house that’s held up for more than ten years).
But this wasn’t a cheap chair – the ottoman (where you rest your feet) was something like $500. I remember thinking, that’s what I’d normally spend on a chair!
So I saved. And I saved. And eventually I got my chair. And I’ve loved it ever since.
I Do Not Make Chairs
Here’s the thing. I don’t make chairs. And yet, when I work with clients, sometimes I think they want me to build their software in the same way that craftsmen do when they create chairs like mine.
I’ve even heard developers talk like that. To each other. And to clients.
But I think there are some seriously messed up consequences to these comparisons.
The Craftsman Paradigm
When we think about building software in the way craftsman build chairs, we think of software that will last a long time. That’s a great thing. But it comes at a price.
Because when you think about chairs you know some other things too: our use of them hasn’t changed in decades. They have a simple and single purpose.
And that’s when we see the difference and the challenges when it comes to software. When we live in the craftsman paradigm, we think of software as static with single intentions, but that doesn’t look anything like reality.
Reality is that we’re often building something whose purpose is only generally articulated and plans to be used to meet several goals, defined by several users.
The Result of Living with the Wrong Paradigm
Here’s what I know. When I interact with serious and smart software architects, especially at the outset of building a large new system, they always want to talk about scale.
They want to build it right the first time. They want to make sure everything scales. They want to make sure they don’t have to throw anything away. They want to make sure that the design they create will support a system that will last as long as my chair.
After 19 years of building large enterprise software systems (often as a hosted solution), I can tell you they’re almost always wrong.
When you live in the wrong paradigm, you make poor choices.
And before you flame me, I’m not suggesting you don’t think about architecture before building a large system. I’m simply saying that it’s incredibly difficult to get it right at the very start.
Also, I’m saying nothing about intention. I know they’re all trying hard. I know they’re all smart. They’re just living in the wrong paradigm.
Here’s Why That Doesn’t Work
Let’s do a thought experiment.
Ask yourself how smart you were two years ago. Now compare it to today. Are you smarter?
Let me answer that for you – yes.
In almost every case, most engineers I know get smarter over time. Stated another way, in a way that relates to my argument, architects learn about their intended system after they see it in use, and then become much smarter about how to make sure the design could be optimized.
Time has a way of serving us, if we let it. That’s not being lazy. That’s being efficient and resourceful. Let time do its work.
Instead of designing scale into a solution up front, limit that desire and simply get a product complete and into the market so you can see how people intend to use it. It will help you know where to adjust it (for scale).
Scale isn’t the only dynamic where we burn too much time up front trying to front load perfection and longevity into our designs. We often do the same with usability.
Now, don’t get me wrong – there’s always going to be some baseline of usability that if you don’t get right, will kill you. But you don’t need to design the newest interface to launch a product that people will use. After all, consider all the people that used VCRs without ever setting the clock.
Trying to design the perfect interface before seeing where people get stuck, or where people spend their time, can easily become a never-ending puzzle that has no right answer (and is just costly).
Again, I’m not saying throw trash out there. I’m simply saying, the craftsman paradigm will catch you and send you into overshoot really easily.
I Don’t Like to Overshoot Things
My code won’t last forever.
I admit it. I often make it explicit to key stakeholders. I highlight how much we’ll all learn over time, including getting natural user feedback from the metrics we collect within our systems.
I highlight that we’ll always have time to adjust and optimize our solutions over time.
But most importantly, I highlight the concept of overshoot. It’s when we overspend (in time and resources) for motivations that aren’t always aligned with the efforts that are explicit.
When you over-architect a solution in advance, for bragging rights (you’re a professional after all), you’re likely to overshoot.
When you over-design a solution in advance, because you’re mildly OCD about perfect design (you’re a professional after all), you’re likely to overshoot.
When you start telling yourself and others that you’re a craftsman who is building software to last, rather than recognizing that you’ll learn and change things over time, you’re likely to overshoot.
And I don’t like overshooting things.