Why constraints are a good thing ⛓
And how to use them to your advantage
👋 Hello!
I was off on holiday last week, and I’m off again tomorrow. I’m spending a few days in Devon, sitting on the beach and eating delicious seafood. Expect another newsletter in a couple of weeks time! 🏖
If it’s your first time reading, here’s a little refresher. The goal of this newsletter is to discuss techniques for building better software and being more effective in high growth companies. I mix in longer form content — think a short blog post that you could read in 5 minutes — with some of my favourite links.
Over the last few weeks, I’ve covered:
Why constraints are a good thing ⛓
After I spent the previous issue discussing the practical applications of static analysis, I’m going all philosophical on you. We’re going to talk about constraints. Dial them in right, and they’re a great tool to have in your arsenal. Let’s get into it!
What are constraints?
Wikipedia defines a constraint as the following: ‘In mathematics, a constraint is a condition of an optimization problem that the solution must satisfy.’ Generalised, we can think of a constraint as a limitation or restriction on what you’re able to do and/or how you might do it.
They may be real — no money in the bank to hire people! — or artificial — an internal project deadline set by a manager, with no downsides if that deadline is not hit.
What are some common constraints?
The classic ones are time, cost, scope: pick any two! There’s a few additional ones you’ll see in high growth companies:
Time: “we need to build this feature by Friday”
People: “a web engineer won’t be free to help on this feature for another 2 weeks”
Cost: “we can’t afford to hire another backend engineer”
Workload: “we need to do both X and Y at the same time”
Performance: “you can’t ship any change that makes the website slower”
Why are they useful?
On the surface, it might seem that constraints are bad things. They make tasks harder, and limit our ability to do our job. I disagree. Scratch a little deeper, and they’re very powerful if used correctly.
Constraints breed discipline
The inverse of the sub-heading is more true: the lack of constraints tends to breed bloat.
There’s a well-trodden path for high growth companies after they receive their first large funding round. Both the constraint of capital, and the constraint of saying no are instantly removed. As a result, they tend to dramatically over-hire, or over-parallelise and spread themselves too thinly. The organisation loses discipline and focus. Products take longer to ship. Targets get missed.
Is this inevitable? No! Remember — software as a medium has tremendous leverage. It always surprises me what you can do with a small number of people. The classic example here is WhatsApp: they built a service that scaled to 450 million users with an engineering team of 35. Closer to home, Monzo built a fully licensed UK bank — mostly running on software build from the ground up — with tens of engineers.
Over time, I’ve grown an appreciation for the organisational discipline that constraints provide you with.
Constraints compel you to think carefully about scope
In a world where you could feasibly build anything with software, constraints constrain the realm of possible things you could build.
This can be really helpful! It makes it easier to make decisions about what solutions are feasible, given those constraints.
The constraint of time is very useful here — often called timeboxing. Given that you need to ship something by the end of the week, what’s the most useful thing you could build in a week to see if you’re on the right track? This helps avoid over-engineering, and forces you to reduce scope to something more manageable.
Quick plug: if you’d like to read about how to scope work better, here’s a previous issue I wrote about it!
Constraints force you to say no
Following on from the above point, it’s often wise to avoid doing anything at all. In the face of many constraints, say no to as many things as possible in order to retain optionality. I’ll leave this one to Steve Jobs to expand on.
People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I'm actually as proud of the things we haven't done as the things I have done. Innovation is saying no to 1,000 things.
Constraints are a forcing function for adaptation and improvement
Here’s a story from Ravelin to illustrate. We built machine learning models to try and spot chargeback fraud on behalf of our clients. We used these models to make predictions about whether a particular payment was likely to be fraudulent, blocking it if it reached a particular probability. Fraud isn’t constant: it’s a constant game of cat and mouse. To react to new trends, we would periodically retrain these models with new data, and replace the old model.
A constraint was that the percentage of transactions we blocked with the new model must remain the same as with the current model. This was a fantastic constraint! It meant the only way we could stop more fraud was by the underlying model becoming more discriminative and accurate, and better at stopping fraud. The alternative would have been to allow us to simply reduce the threshold at which we called something fraud. This would have meant we would have stopped more fraud, but only by inconveniencing more genuine customers: not because the model was necessarily any better.
This can be generalised to software performance. If you want a fast piece of software, introduce a continuous integration check that forces all changes to be faster than the previous version on a benchmark, failing the build if it is slower. Any new features that slow the system down must be ‘paid for’ by finding performance optimisations in the existing codebase that outweigh the new cost. It’s a harsh way to achieve it, but you’re guaranteed faster software at the end of it!
A parting note
Constraints are just a fact of life. But, most of them can be turned into a positive if viewed correctly. You don’t have enough people? Usually, you do — you’re just doing too much at the same time, or doing the wrong thing. The constraint is giving you feedback that wouldn’t be possible if it wasn’t there. Learn to love them!
Best of the internet 🔗
Every week, I collate some of my favourite links to share. Found something cool, or built something great? Send it to me by replying to this email and I might include it in the next edition. 📧
Building a Grafana dashboard for your bank - Alex Russell-Saw
What it says on the tin. Pretty cool! Presumably you can hook up alerts as well.
How to create near real-time models with just dbt + SQL - Amy Chen
A nice walkthrough on how to use dbt to achieve near real-time data models, whilst keeping complexity low.
The Work-From-Home Shift Shocked Companies - Wall Street Journal
I included this for a selfish perspective: I’m so tired after a day of video meetings. Can we please go back to phone calls, or do the meetings asynchronously? Paywall. 💰
That’s all from this week’s High Growth Engineering. If you enjoyed it, I’d really appreciate it if you could do one of the following:
Share it with a friend that would find it useful.
Follow me on Twitter: @sjwhitworth
Subscribe: just hit the button below.
All the best,
Stephen