- The Blend
- Posts
- ☕ The Blend - Issue #9
Hi Friends,
In this issue I would like to tackle the topic of why work is never “just work”. I’ve lately came across a great Linkedin post that was touching the area of estimation.
Before diving in, I think it’s worth starting with a great quote by Tom Cargill
The first 90 percent of the code accounts for the first 90 percent of the development time.
The remaining 10 percent of the code accounts for the other 90 percent of the development time.
Which is true, and catches the perspective of almost every single IT project. People suck at estimation, especially when it comes to problem solving, period. Every single project is either underestimated, or highly overestimated. And it’s almost impossible to estimate precisely.
I’ve touched on the metrics in my previous newsletters, and I’ve mentioned there that if we’re gonna measure development success eg. based on estimations - people will simply double/triple them. Meaning they’ve already are crippled.
Why estimations are hard?
The simple answer is - because you’re unable to predict the future.
But there is a multitude of other smaller or bigger factors that will influence it. Let’s break down couple of them 🤔
You’ve never done it before - maybe you’ve done something similar, but probably never exactly the same.
People can change - you’re working on the team, and one of the members resign, or there is a new comer that you have to onboard - both scenarios will impact the estimations and delivery date.
“Apples to Apples” - an estimation will be different to people with different skillset. A task can be done in 1 day by a senior developer, but will require more time for a junior developer.
You’re a weak link a chain - We’re not robots, we tend to guess wrong, forget about something etc.
Estimating is a skill - you can get better at it. You can gain more experience with each finished project. But that not necessarily mean you’ll be 100% accurate.
What are the components of ‘the work’
I’ve found a great graph, that was created by Dave Stewart
Dave Stewart
It roughly shows how much moving parts there are, beside the ‘actual work’, and they all influence the overall estimation, Dave broke it into 8 categories:
1️⃣ The work around the work — meetings, reviews, project management
2️⃣ The work to get the work — research, experimentation, scoping, quoting, pitching
3️⃣ The work before the work — configuration, setup, services, infrastructure
4️⃣ The work — the actual build, design, and testing of the product
5️⃣ The work between the work — iteration, debugging, refactoring, maintenance, tooling
6️⃣ The work beyond the work — changes, omissions, nice-to-haves, scope creep
7️⃣ The work outside the work — surprises, contingency, disasters, mission creep
8️⃣ The work after the work — hosting, deployment, security, support, updates, fixes
In one of my project, we were working on the Google Chrome Extension, and I felt really comfortable that I can deliver an MVP within 6 weeks timeframe. We’ve created the scope, the developer started the work… and yes, within 6 weeks we’ve had a working solution, it wasn’t perfect, but it was working. The final product though, which was delivered to the clients - took us about 2-3 more months. Just when I thought I am at 99% done, I’ve actually been around half way 😉. Yes, this means that the scope must have been crippled, but actually the itteration proved, that we didn’t know everything when we’ve started working on it. Another issue was QA on different environments, hardwars produced a lot of bugs, we’ve had to cover etc. etc…
There is so many components, that it’s impossible to take them all into account.
How to tackle this issue?
There are couple of approaches one can take to make estimations more precise, OR to stop using them in favour of something else.
You can estimate in days, in points (most common way is to use Fibonacci sequence), quarters (by giving a very rough ballpark estimation).
You can also reverse the approach and instead of estimates, start using appetite. This approach was introduced by 37signals in their book called Shape Up. Showing their unique way of building software.
You can think of the appetite as another part of the problem definition. Not only do we want to solve this use case, we want to come up with a way to do it in six weeks, not three months, or—in the case of a small batch project—two weeks, not the whole six weeks.
Stating the appetite in the pitch prevents unproductive conversations. There’s always a better solution. The question is, if we only care enough to spend two weeks on this now, how does this specific solution look?
Anybody can suggest expensive and complicated solutions. It takes work and design insight to get to a simple idea that fits in a small time box. Stating the appetite and embracing it as a constraint turns everyone into a partner in that process.
No matter which path you’re going to follow, the most important part of each project is to break the pieces down to the smallest task possible. If the task is small, it’s easier to estimate it precisely.
There are more benefits to that approach. I’ve mentioned it in the topic about engineering metrics - the smaller the PR is, the easier is to merge it (faster code review, less conflicts, easier to understand).
I wish a good luck with your future estimations, and hopefully this articles shed some light on this vague topic.
💌 Subscribers’ special
Don't miss out on these insights. Subscribe to my newsletter now and be the first to receive the latest issue of ☕ The Blend straight to your inbox.
🎁 Subscribers also get hand-picked links to valuable articles, videos, tools and apps.