There are many things that I loved about my parents. There are also some things that went into the regrets bucket. They gave me an eating disorder. It was not just me, and it was not really their fault. A whole generation of people grew up with an eating disorder. I have compared notes with many of my other GenXers, and many of them share the same affliction. It is admittedly a first-world problem, and I have resolved to break the circle of violence to make sure that I do not give my kids the same eating disorder.
When I was a kid, whenever we sat down to dinner, we voraciously attacked specific dishes because they were prepared in fixed quantities. There was always plenty of food… We were not starving… My mother had a formula for preparing specific dishes, which generally worked out to “two hamburgers per person,” for example.
My brothers and I happened to love hamburgers. Two hamburgers are enough of a meal from a nutrition standpoint. Sometimes, we would fixate on a different number of burgers, like three.
You might see where this is going.
We were always welcome to take whatever we wanted until it was all gone. It was also a little bit “first-come-first-served.” The problem would sometimes arise when we would take an extra homemade bun or burger paddy and not have room for it all.
Our parents grew up during a difficult time, and there were times when they did not get enough to eat. They did not really have the luxury of being able to eat whenever they wanted, and it was one of those things that would drive them up the wall.
If you sat at the table and could not finish your plate, you were in trouble.
Some people have parents who yell. Some people have parents that were physical when they were upset. My father’s superpower was a cold and level stare followed by a quiet judgment delivered in a voice barely above a whisper while shaking his head sadly.
When you sat there with your plate of uneaten food, he would start with, “What is the matter? Are your eyes bigger than your stomach?”
This was often followed by a wartime anecdote or comparisons to people starving in third-world countries. My mother had her versions of this, except it was heaped up with guilt over how hard she worked to put that food on the table. She had expert command of weaponizing Roman Catholic guilt.
As a result, I spent the next twenty to twenty-five years fastidiously cleaning my plate.
I am glad that I have not inflicted this condition on my children. I do not dress them down for eating only as much as they want. I can pick up a plate half full of food and throw it away. Many times, I inwardly wince and feel the heated glare of my parents staring down at me for allowing food to go to waste. I have broken the circle.
Believe it or not, this story does have something to do with software development.
Let’s talk about software estimation!
If you spend any time building software or teams, you eventually want to get to “done”. As you spend more and more time building software and eventually growing either your products or organizations, it becomes important to know when in the future stuff becomes “done”… So you can start planning for the next bucket of deliverables, and also maybe rearrange the resources for various reasons. This requires you to track your software development somehow.
There are as many ways to track software development as stars in the sky. And almost all of them are wrong.
Quite often, engineers’ eyes are bigger than their stomachs. See how I brought that home?
Even in the time that an engineer has sized their work correctly, sometimes things break in production that require their attention, or a part of the feature in development develops an edge case or wrinkle that suddenly changes the amount of work to be done or the amount of time remaining—for the worse.
Yet everyone in leadership constantly tries to figure out when stuff is done. This is especially true when we want to hit enterprise customer deadlines or important consumer-related dates.
There is no user story that says:
“As a software engineer with bad estimates, I wish Christmas to happen on January 3rd.”
There is no Hallmark Christmas special where engineers return to a small town only to get a different Christmas date so they can complete all of their work; I would probably watch it if there were.
Heck. Even I am bad at doing software estimates. Before I give anyone an estimate, I have to hold myself accountable and declare John Szeder’s Two Week Rule.
Nothing in software development takes two weeks. It either takes three days or one month.
Every single time I have said, “This will take two weeks,” I have been wrong. Sometimes by the number of weeks, sometimes by an entire category shift of time units. Sometimes, I have even been wrong at both.
This is one of the reasons I like two-week sprints. It is so hard to fit a single task into a two-week window that you invariably start breaking tasks down into smaller pieces to fit them more completely into the two-week window.
If you are a planning poker person, and often I am, then your Fibonacci sequences are handy here. Historically, I have pegged some projects to 2 story points of work equal to a single day (of 6 to 7 hours, depending on the organization), and if you break your tasks into Fibonacci numbers, getting to a perfect 20 points is a struggle.
When you get to a big enough team, twenty engineers or more, for example, you can start measuring organization velocity quite nicely with a system like this.
The variance from engineer to engineer on productivity gets smoothed out in the total points allocated sprint-over-sprint, and people think more accurately about how much they can accomplish.
When you start to do planning poker, you generally have really wide variance on your teams for the number of points they sign up for versus the number that gets accomplished.
This, in itself, is okay. What you want to do is to address that in future sprints. It does not matter if your first sprint was largely noise and your team completed 10 of the 60 points they signed up for.
If they get 30 of the 60 possible points next time and continue to whittle away at the gap between “How many points do we think we can do?” and “How many points did we actually do?”, your team will be successful.
You will not have a perfect estimation.
You will be close enough to it that you should not care.
So much like anxiety-ridden John staring at his half-eaten homemade hamburger, you should not care about your appetite. You should not care if your eyes are bigger than your stomach.
Instead, you should consider how much food to put on your plate the next time.
I will leave you some time to digest this clever metaphor.
See you all next week!
