Questions for software engineers about estimates.

✿ Floby 💉😷💨

@polotek These days I try to focus on having conversations about delay rather than effort because the main difficulty in my org right now is that priority is shifting constantly (not always for good business reasons) and we're already doing many things in parallel. None of our projects is very complex, but the bulk of what makes it hard to estimate when things will be done is that people get reassigned constantly to other tasks, which results in effort & delay being uncorrelated for a given task

Marco Rogers

Okay. I can give some if my answers to the question about estimates. I've never been presented with formal methodologies around estimation. In my early career, it always seemed like more senior people would just come to with numbers based on fuzzy intuition and experience. This never really bothered me. It's just the way things were done.

Marco Rogers

The reason it was mostly okay is that my early career was as a contractor. I worked for firms that hired me out hourly. Estimates were just estimates. If it took longer, we would explain why and renegotiate the hours. There were conflicts sometimes. We missed something huge on our side, the client was in a bind and couldn't afford to move dates, etc. But none of that fell on me directly as a team member.

Marco Rogers

When I became a Senior Engineer, it's because they wanted me to lead projects. But I became the person who had to answer the question "how long do you think this will take?"

At this point, I had observed a lot of what more senior people talked about and thought about when they did estimates. I paid attention when they asked me questions about my part of the work. So I started to model those things I had seen.

Marco Rogers

One of the key things here is that I still had string mentorship and guidance. There were always people around who were more experienced then me. I talked to them directly and explained my thinking. And they would either say "yeah that seems reasonable" or they would say "uh, no that doesn't seem right. Let's talk about it some more."

Marco Rogers

This was 20 years ago. The industry has shifted in and pretty big ways. As a manager for the last 10 years, I've had different experiences growing teams of engineers. Many of them have the impression that their instincts are the only ones that matter. Many people react poorly to being told "uh, no that's not right."

At the same time. Many engineers are starved for experienced mentorship where none is available. There's nobody else to talk to about whether their estimates are any good.

Marco Rogers

I didn't realize at the time that the support I had early in my career was not only good but also atypical. It wasn't until my 3rd job that I had my first experience of managers and more senior dev who were unhelpful and also not better than me at what we were doing. That was wild. And pretty frustrating.

julian

@[email protected] story points make no fracking sense.

They make sense within the context of a team so long as the team is roughly aligned with how much a point is "worth", arbitrarily.

And then of course they loop in contractors and other teams that don't share the same point worthiness and suddenly are surprised when the estimates make no sense.

julian

@[email protected] for what it's worth I'm pretty bad at estimating. It drives @jay-moonah up the wall

Marco Rogers

But back to estimates. My process for estimates is still pretty informal. Some folks here have pointed to books and blog posts that outline much more rigorous methods. But that doesn't appeal to me. I gravitate towards work environments where keeping things informal is expected. And that usually means there is a lot of flexibility in determining the tradeoffs. E.g. timeframes or scope of work.

Marco Rogers

Here are some the heuristics I tend to use.
* If you're giving hard estimates further than 3 months out, you're probably making it up.
* We can and should break large efforts down into phases or milestones. Those should target 3 months or less so the estimates can be meaningful.
* Getting good at swaging these 3 months milestones means you *can* give fuzzy estimates about large efforts. 4-5 milestones means "this could easily take 18 months".

Marco Rogers

* Estimates will vary greatly based on the size and experience of the team.
* Part of the job of a project lead is to break down the work into manageable chunks. This is largely where we *design* the system to be built. Hint: this part is missing in a lot of dev processes.
* Below two weeks or so of work, the ownership should be given directly to the engineer who will do the work. If they say yes, then we're good. As I told someone earlier, I hate "story points" with a fiery passion.

Marco Rogers

I'm fairly confident in my estimates. But what does confidence mean? It does not mean that I hit my estimates all the time. It means that I think my estimates are meaningful and useful for doing planning work. I am also confident in my ability to adjust my estimates as things become more clear. And I'm confident in my ability to communicate these changes clearly to stakeholders so they can decide what they wanna do.

Marco Rogers

Here are some things that I do to make sure I have high confidence in my estimates.
* I talk to my team and learn what they are capable of. As a manager or as a peer engineer. Estimates don't mean anything if the other people involved won't or can't do what is asked.
* I quickly identify which parts we are not experienced in. What things are outside of our current experience and competence. Those parts are labeled high risk.

Marco Rogers

* I front load the high risk parts. Meaning we work to explore those parts early in the project. The sooner we gain clarity, the sooner we can refine the estimates. You can also do short proof of concept sprints to achieve this goal.
* For anything longer than a few weeks, I create documents to outline the important decisions and assumptions I'm making. I loosely refer to these as Project Documents. And in my opinion we don't do enough to teach people how to create these.

Marco Rogers

For any less than a month, we don't need to do a lot of paperwork. Just create a one-pager and then let's just go do the thing.

I should round this out by wrapping it in some context. The statement above implies the kind of environment that I prefer, and thrive in. A fast-paced one where we develop and ship changes in relatively short increments. In recent years, that has meant high growth tech startups. These guidelines won't work as well in other kinds of environments.

Marco Rogers

@floby I don't like talking about "delay". It leaves out the part where we're getting smarter about things as time passes.

✿ Floby 💉😷💨

@polotek not necessarily, when looking specifically at lead time for example, the expectation is that you can bring it closer to 0. To me that translates about a team getting smarter about their code authoring and testing practices, their necessary vs unnecessary dependencies and the maintainability of their code base.
But as I said, I'm more trying to find which tool is going to get the number of ongoing initiative per developer below 1.

Marco Rogers

@floby uh, all of these things are about getting smarter over time. What am I missing?

✿ Floby 💉😷💨

@polotek yes, they are, but I was pointing out how I don't think that talking about delays prevents accounting for the team getting smarter.