Iron triangle, cloud vs on-prem, engineering metrics 💡
Monday Ideas – Edition #59
Hey, Luca here! Welcome to the Monday Ideas 💡
Every Monday I will send you an email like this with 3 short ideas about making great software, working with humans, and personal growth.
You will also receive a long-form, original article on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!
p.s. you can learn more about the benefits of the paid plan here.
🔌 Speakeasy — create SDKs for your API
This week I am happy to recommend Speakeasy, which helps you improve your API's usability in minutes.
Speakeasy integrates into your CI/CD to make the creation of idiomatic, type-safe SDKs in 7+ languages touch-free.
And, this week, they are releasing a whole host of new features. To see the latest in SDK creation, follow the link below:
Speakeasy is a sponsor of Refactoring 🙏 here is how we run sponsorships transparently.
1) 🔺 The Iron Triangle of Planning
Consider the Iron Triangle of Planning, proposed by Martin Barnes in 1969.
It is based on the assumption that Scope = Time * Resources, and supposedly you can change one dimension to impact the others.
However, trading between these constraints is not always possible.
In particular, resources (or budget) often don’t have an immediate impact on the other two. You can't usually say "I want to pay twice as much so you can deliver the app in half of the time", because:
In most projects this is straight impossible — 9 girls cannot make a baby in 1 month.
Resources are not responsive — new people on the project need onboarding, coordination, etc.
To deliver a project faster, your best bet is to act on one of the two other dimensions:
Reducing the scope, or
Increasing the time for delivery
You can find more ideas about planning software in the latest Refactoring edition 👇
2) 📊 The three uses of engineering metrics
Metrics about team productivity have come a long way and today we have plenty of tools and workflows that genuinely help the dev process.
Many managers and devs, though, have false expectations or don't know how to use them.
Let’s put it up front: no metrics will tell you how well your team is working, as a whole. If you are looking for a holistic picture of your team’s performance, that still comes from your experience.
Metrics are clues. They empower your processes and give you a sense of where the wind is blowing.
I have used engineering metrics for many years, and here is what they have been the most useful for:
📈 Spot trends
Sometimes it’s hard to pinpoint a good target for a KPI, but you can spot whether things are improving or not.
E.g. the # commits/day isn't much actionable in isolation, but what if you see a steady decline in the last three months?
Spotting a trend makes you ask questions, that can often be answered with metrics, too:
Are we getting slower at PRs, too?
Maybe that’s because we are having too many meetings?
Or is there too much work in progress?
💬 Start conversations
Once you have spotted a trend, numbers make it easy to start a conversation with your team.
Such conversations can range from celebrations, for when things have improved, to figuring out the root cause of a problem, starting with some evidence. Which leads to the last point 👇
📣 Back initiatives
Numbers can provide evidence that backs initiatives with stakeholders.
E.g. showing that your team routinely spends 40% of their time on maintenance is a great starting point to advocate for some debt-reducing project.
You can find more ideas about how to use engineering metrics in this recent article 👇
3) ☁️ Cloud vs on-prem == buy vs build
The whole debate about cloud vs on-premise infra follows the classic rules of buy vs build.
My rule of thumb is that you should:
🔨 Build — whatever is strategic to your business and you can turn into a competitive advantage.
🛒 Buy — just everything else.
So, when is infrastructure strategic? Whenever it plays a decisive role in preserving important qualities of the business. Among them, two crucial ones are velocity and profits.
⚡ Velocity
In startups and high-growth businesses you need the agility to steer the ship fast to meet ever changing requirements.
There is no way around the fact that owning your infra makes you less flexible than staying on the cloud. Again, your mileage may vary based on your team and skills, but whenever you need to spin new instances, resize existing ones, or set up a managed service, you are going to be faster on the cloud.
💸 Profits
In high volume + low margin businesses, infrastructure may considerably eat into profits. Think of cloud storage, like Dropbox, or ad-supported businesses, like social networks.
We tend to think that whenever you have high volumes you are better off owning your infra, but that’s not necessarily true. It is only true when you also have low margins.
Netflix has more traffic than Twitter, but the former runs on AWS, while the latter runs its own datacenter. That’s because of margins.
You can find a thorough comparison of cloud and on-premise infra options in this past Refactoring article 👇
Dopt — build quality product onboarding
Dopt gives developers a component library and SDKs to build seamless product onboarding and education in minutes.
🔀 Visual flow builder — lets the team map out targeting, content, and branching logic.
📦 Prebuilt components — customizable React components like checklists and tours offer best practices and help you ship quickly.
🛠️ SDKs and APIs — let you build to your exact needs and make it easy to develop flows in your app.
Dopt is a sponsor of Refactoring 🙏 here is how we run sponsorships transparently.
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. You can learn more about the benefits of the paid plan here.
2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca