Over the course of this week, I'll be writing daily emails to my team at Crowd Favorite (the developers). My hope is that they'll challenge my team while also giving them insights into how I think about things. The reality, however, is that these ideas aren't just for my team. I believe they're for any folks doing web development and project work. Which is why I thought you might like to see them here on chrislema.co.
So without further editing, here is day 1's email.
Let’s start today by thinking about constraints.
Constrained but Straightforward Environments
Particularly I want to talk today about highly constrained environments. By this I simply mean where there is no (or remarkably few) degrees of freedom.
One kind of environment like that makes cause and effect really clear.
When you build a factory to produce chairs, the cause and effect are often plain as day. You know exactly what needs to be done. You can't make a chair without a seat. You need a certain amount of legs, etc. There is no need (for the basic chair) for a domain expert in chair fabrication. If you make poor cuts on your wood, you'll waste it, and it will immediately impact your yield. It’s plain as day.
These are simple environments with high constraints. In that world of chair manufacturing, the steps are clear, the work is clear, and the consequences are clear. You know that a certain amount of supplies will result in a certain number of chairs.
This is where best practices come in.
If you're getting 72% yield from your supplies, and someone else is getting 80%, you'll ask them and they may look and quickly find what you're doing that is suboptimal. They point it out, you adjust, and you too will get that kind of result.
Constrained and Complicated Environments
There is another highly constrained environment which isn't as simple and obvious. But it’s still constrained.
Cause and effect are still there, but they're harder to see to the plain eye. In this case you do need a domain expert.
Think about taking your car into a trained mechanic.
I know nothing about cars. I’m useless other than saying, “it’s making a strange sound.” So cause and effect are hidden to me. But they're still knowable.
The other tricky part of this is that two mechanics may analyze similar cars and come up with two legitimate approaches to solving a problem. These two approaches may be equal in resolution but wildly different in approach.
This is where we start to see the erosion of “best practices.” Because now we're talking about “good options” rather than a single best way of doing things.
And that’s because in that context, where there is complicated work that requires expertise and analysis, there is no “best practice.”
We're not building chairs or fixing cars…
I'll write more about this tomorrow, but for today, let me simply end where I began.
When we're talking about software projects for hire, even websites, we're not making chairs or fixing cars, and there is no best practice.