4 ms·

> The other problem is that programming is not simply "development", it's research too. Research can be a bottomless hole, and it's also really hard to estimate

by i5h4n 6y ago

> The other problem is that programming is not simply "development", it's research too. Research can be a bottomless hole, and it's also really hard to estimate how much research is needed. This. As a programmer, I've never been able to successfully explain to my managers about this. It always ends up being a blame on me instead for "not properly assessing and estimating the effort".

bryanmillstein 6y ago
This will continue to be a challenge because humans are simply not great at estimating. I have had success by explaining to managers that a big part of my job is to help them manage risk. In order for me to do that properly I typically need more information than is initially present so that I can give a high confidence estimate. I might say something like, "I can give you a low confidence ball park estimate right now but if you give me a few hours to research then I can greatly increase the confidence level." After all, you know the least about a project at the beginning therefore no one should have a high degree of confidence in estimates given then.
- muzani 6y ago
  Yeah, this was how I was trained to do it. A ballpark estimate on the spot at best is around 30% accuracy. I normally wouldn't give an estimate unless I can break it down the work into less than 4 hour chunks. Proper estimates also contribute to work done as it involves the design, but it's normal to spend a few hours doing estimation. Trained managers are familiar with the cone of uncertainty, though. But what I really mean is stuff on the level of powering a toaster with a car battery. It's certainly possible, but nobody has documented on what they did, and there's a very high number of uncertainties as neither were designed to perform this way.
  - bryanmillstein 6y ago
    I think you nailed it by pointing out how overlooked the research part of development is. Technical folks often understand this but it can be a challenging concept for people who have not worked as a developer. They can have a distorted view of the research to coding ratio. I imagine they often believe that writing code takes up 90% of a developer's time when in reality time spent researching and thinking is the dominant activity.

by i5h4n 6y ago

bryanmillstein 6y ago

This will continue to be a challenge because humans are simply not great at estimating. I have had success by explaining to managers that a big part of my job is to help them manage risk. In order for me to do that properly I typically need more information than is initially present so that I can give a high confidence estimate. I might say something like, "I can give you a low confidence ball park estimate right now but if you give me a few hours to research then I can greatly increase the confidence level." After all, you know the least about a project at the beginning therefore no one should have a high degree of confidence in estimates given then.

muzani 6y ago
Yeah, this was how I was trained to do it. A ballpark estimate on the spot at best is around 30% accuracy. I normally wouldn't give an estimate unless I can break it down the work into less than 4 hour chunks. Proper estimates also contribute to work done as it involves the design, but it's normal to spend a few hours doing estimation. Trained managers are familiar with the cone of uncertainty, though. But what I really mean is stuff on the level of powering a toaster with a car battery. It's certainly possible, but nobody has documented on what they did, and there's a very high number of uncertainties as neither were designed to perform this way.
- bryanmillstein 6y ago
  I think you nailed it by pointing out how overlooked the research part of development is. Technical folks often understand this but it can be a challenging concept for people who have not worked as a developer. They can have a distorted view of the research to coding ratio. I imagine they often believe that writing code takes up 90% of a developer's time when in reality time spent researching and thinking is the dominant activity.