6 ms·

TFA uses a lot of words to say very little. I don't care if your estimate is drawn from the hip or projected using a state of the art Monte Carlo or machine le

by idoby 6y ago

TFA uses a lot of words to say very little. I don't care if your estimate is drawn from the hip or projected using a state of the art Monte Carlo or machine learning model. It's still an estimate. Still, any number of things that weren't in your model could shift the deadline: people getting sick for a long time, people quitting, people getting promoted out of their critical role, organizational dependencies not delivering on time (other dev teams, legal etc), all of these things have happened to me, and when they do, they can throw off your project for months. No model can take these things into account, and if it does, it will yield an estimate like "three weeks up to a year" which is useless, and I didn't need your SOTA model to get that answer. Unless you're really only doing cookie cutter stuff, the best form of estimate I've seen used is continuous estimation + being willing to cut features to make it to deadlines with something usable, even if incomplete (build a bike, not half a car). This isn't always possible, but when it is, it saves a lot of headache and makes everything run smoother. But it starts with accepting the fact that you don't know everything from the start.

mwilcox 6y ago
Came here to say this. If we can't forecast the economy at the scale of millions of people and trillions of data points you're not going to be able to forecast a company. We should focus on building organisations that are robust enough to withstand challenges that are thrown at them
- Enginerrrd 6y ago
  We CAN forecast a lot of those things. The problem is that people either don't think in terms of cinfiy intervals at all, or they neglect the 2.5-5% on the tails.
allenu 6y ago
I think that attitude is the right one. Make decisions as if you cannot predict the future and you will be on a better path than one where you think you can. The way I look at it, you have the most unknowns and risk at the start of a project and the least at the end. As you work on it, you learn about the domain of your problem space and the possibilities and impossibilities of what you can do technically, as a result, those unknowns and risks go down. With that in mind, structure the work you do so as to front-load as much learning as possible to help reduce risk and get a better bearing on how long it will all take. And yes, be able to cut features if that target date is more important than the ideal product goal you set out with.
erpellan 6y ago
The article is about forecasting not estimation. That's the point. Don't estimate. Measure. It usually goes without saying that most forecasts do not include provisions for black swan events. It's generally assumed that going bankrupt or other project externalities will have an impact on the delivery.
- dirklectisch 6y ago
  Author of the article here. I agree with this response. We are normally not asked to predict for situations where something big changes in the team. But I of course acknowledge that these things do happen. When you have a stable team, the numbers that this method yields are also very stable.
  - qhalCAZ 6y ago
    I agree with the top comment. The "method" is basically: Instead you can look at the team’s historical data and apply statistical techniques. Except that is already what every experienced developer is already doing, albeit in an intuitive way. Intuition is superior here, because statistical models don't work for creative domains, and anyone who says so has something to sell.
    - coldcode 6y ago
      If you build a general ledger application for the 10th time, sure forecasting is fairly straightforward. Nothing I do at my (very large, non tech but highly software driven) employer has ever been done before here. All estimates are treated officially as if they are date time accurate, but changes happen during the lifetime of the project so often you may as well use a random number. I call it a "nod nod wink wink" estimate: every wants it to be accurate, but no one really expects it to mean anything, other than the budget people.
      - waheoo 6y ago
        One of my favorite managers required i give him estimates. I hated it because we both knew the number was bullshit. On the other hand, having to think about the estimate and give him something, even if at times it was a guess, i still found it beneficial. It meant i focused better, stayed on task, and often delivered on time anyway. Im not saying everyone needs the accountability rails, but some people excell with this particular helper.
andrei_says_ 6y ago
I like and have been using Basecamp’s Shape Up process. https://basecamp.com/shapeup https://basecamp.com/shapeup

by idoby 6y ago

mwilcox 6y ago

Came here to say this. If we can't forecast the economy at the scale of millions of people and trillions of data points you're not going to be able to forecast a company. We should focus on building organisations that are robust enough to withstand challenges that are thrown at them

Enginerrrd 6y ago
We CAN forecast a lot of those things. The problem is that people either don't think in terms of cinfiy intervals at all, or they neglect the 2.5-5% on the tails.

allenu 6y ago

I think that attitude is the right one. Make decisions as if you cannot predict the future and you will be on a better path than one where you think you can. The way I look at it, you have the most unknowns and risk at the start of a project and the least at the end. As you work on it, you learn about the domain of your problem space and the possibilities and impossibilities of what you can do technically, as a result, those unknowns and risks go down. With that in mind, structure the work you do so as to front-load as much learning as possible to help reduce risk and get a better bearing on how long it will all take. And yes, be able to cut features if that target date is more important than the ideal product goal you set out with.

erpellan 6y ago

The article is about forecasting not estimation. That's the point. Don't estimate. Measure. It usually goes without saying that most forecasts do not include provisions for black swan events. It's generally assumed that going bankrupt or other project externalities will have an impact on the delivery.

dirklectisch 6y ago
Author of the article here. I agree with this response. We are normally not asked to predict for situations where something big changes in the team. But I of course acknowledge that these things do happen. When you have a stable team, the numbers that this method yields are also very stable.
- qhalCAZ 6y ago
  I agree with the top comment. The "method" is basically: Instead you can look at the team’s historical data and apply statistical techniques. Except that is already what every experienced developer is already doing, albeit in an intuitive way. Intuition is superior here, because statistical models don't work for creative domains, and anyone who says so has something to sell.
  - coldcode 6y ago
    If you build a general ledger application for the 10th time, sure forecasting is fairly straightforward. Nothing I do at my (very large, non tech but highly software driven) employer has ever been done before here. All estimates are treated officially as if they are date time accurate, but changes happen during the lifetime of the project so often you may as well use a random number. I call it a "nod nod wink wink" estimate: every wants it to be accurate, but no one really expects it to mean anything, other than the budget people.
    - waheoo 6y ago
      One of my favorite managers required i give him estimates. I hated it because we both knew the number was bullshit. On the other hand, having to think about the estimate and give him something, even if at times it was a guess, i still found it beneficial. It meant i focused better, stayed on task, and often delivered on time anyway. Im not saying everyone needs the accountability rails, but some people excell with this particular helper.

andrei_says_ 6y ago

I like and have been using Basecamp’s Shape Up process. https://basecamp.com/shapeup https://basecamp.com/shapeup