6 ms·

Software estimation is something you can get better at if you practice. Throwing your hands in the air because you or you're team is unskilled in the behavior

Software estimation is something you can get better at if you practice. Throwing your hands in the air because you or you're team is unskilled in the behavior is just unprofessional.

tchaffee 6y ago
Over 60% of software projects go over budget, and often by a lot. What's unprofessional is giving estimates for anything that is not small enough to get done in a couple of weeks. You should also understand why someone asks for estimates. They are trying to manage risk. There are far better ways of managing risk than "Brad said it would take three months". Start out by calling it what it really is. It's not estimating. The end goal is risk management.
- codemac 6y ago
  > Over 60% of software projects go over budget, and often by a lot. That's so few! Most companies fold, most construction projects go over budget too. I don't see anyone saying we shouldn't try to get good at budgeting construction, or estimating & planning a project before starting. We're not just managing the risk of failure, we're managing days & dollars! I don't understand why software engineering is the one form of engineering we don't think we need to be able to plan.
  - tchaffee 6y ago
    If you are building something you have built before: a bridge for example, then by all means use your prior experience to budget and plan. The majority of what software engineers build is new territory. Estimating and planning are an attempt to manage risk. And a really bad way of managing risk when you've never built that thing before. Actually starting to build the new thing in question will give you far more useful information about possible time and budget than any amount of planning. And you still won't get it very right. We need to stop pretending that building completly new things is actually possible to estimate. We cannot predict the future and trying to do so is unprofessional.
    - codemac 6y ago
      > The majority of what software engineers build is new territory. I think this is where we just fundamentally disagree. I can send you research about zero defect software, or the economics of software quality, or even research of across many disciplines how delivering value earlier is not in conflict with planning. Time spent planning in all cases saves time and money. However, if you think it's all going to be invalid because of your perception of new territory, then our discussion probably won't go very far. I encourage you to read Capers Jones and Tom DeMarco, but they're not new.
      - tchaffee 6y ago
        Time spent planning does not always save time and money in all cases. We have all seen people who love to build prototypes deliver something working while the guy who insists on planning still hasn't delivered anything. And the guy who built the prototype comes with a list of valuable questions discovered only through the act of building. You wouldn't build a skyscraper in the middle of a busy city without loads of planning, and you wouldn't do loads of planning to build a new product feature for a web application when you are told ahead of time that requirements will change during the build. Knowing which is which doesn't come from reading. It comes from experience. As much I do loving reading about software engineering, like everything else in life you've got to get your head out of the books and ride that horse eventually.
        codemac 6y ago
        "ride that horse eventually" - I'm pretty well on with the horse and riding part, and I make plans I'm held to all the time, from investors, CEOs, and customers. I would have been fired long ago (and have been fired in the past) if I didn't make plans, committed dates, and contracts with customers that managed scope, schedule & budget (see: all of professional program management). Please look up the papers on planning & quality & cost & schedule from Capers Jones. The textbook is literally titled "The Economics of Software Quality". Tom DeMarco's classic is "Controlling Software Projects". I'm trying to give you a starting point to see that it's not even my anecdotes, but repeatable studies that show this. Your examples are that requirements change, and it's hard. Of the few buildings I have built, the requirements changed drastically there in all cases, so I can only say that software engineering is not magically different. After decades of practice with software engineering my experience of planning lines up with the textbooks you can find on the topic, and not this blog post.

Software estimation is something you can get better at if you practice. Throwing your hands in the air because you or you're team is unskilled in the behavior is just unprofessional.

tchaffee 6y ago

Over 60% of software projects go over budget, and often by a lot. What's unprofessional is giving estimates for anything that is not small enough to get done in a couple of weeks. You should also understand why someone asks for estimates. They are trying to manage risk. There are far better ways of managing risk than "Brad said it would take three months". Start out by calling it what it really is. It's not estimating. The end goal is risk management.

codemac 6y ago
> Over 60% of software projects go over budget, and often by a lot. That's so few! Most companies fold, most construction projects go over budget too. I don't see anyone saying we shouldn't try to get good at budgeting construction, or estimating & planning a project before starting. We're not just managing the risk of failure, we're managing days & dollars! I don't understand why software engineering is the one form of engineering we don't think we need to be able to plan.
- tchaffee 6y ago
  If you are building something you have built before: a bridge for example, then by all means use your prior experience to budget and plan. The majority of what software engineers build is new territory. Estimating and planning are an attempt to manage risk. And a really bad way of managing risk when you've never built that thing before. Actually starting to build the new thing in question will give you far more useful information about possible time and budget than any amount of planning. And you still won't get it very right. We need to stop pretending that building completly new things is actually possible to estimate. We cannot predict the future and trying to do so is unprofessional.
  - codemac 6y ago
    > The majority of what software engineers build is new territory. I think this is where we just fundamentally disagree. I can send you research about zero defect software, or the economics of software quality, or even research of across many disciplines how delivering value earlier is not in conflict with planning. Time spent planning in all cases saves time and money. However, if you think it's all going to be invalid because of your perception of new territory, then our discussion probably won't go very far. I encourage you to read Capers Jones and Tom DeMarco, but they're not new.
    - tchaffee 6y ago
      Time spent planning does not always save time and money in all cases. We have all seen people who love to build prototypes deliver something working while the guy who insists on planning still hasn't delivered anything. And the guy who built the prototype comes with a list of valuable questions discovered only through the act of building. You wouldn't build a skyscraper in the middle of a busy city without loads of planning, and you wouldn't do loads of planning to build a new product feature for a web application when you are told ahead of time that requirements will change during the build. Knowing which is which doesn't come from reading. It comes from experience. As much I do loving reading about software engineering, like everything else in life you've got to get your head out of the books and ride that horse eventually.
      - codemac 6y ago
        "ride that horse eventually" - I'm pretty well on with the horse and riding part, and I make plans I'm held to all the time, from investors, CEOs, and customers. I would have been fired long ago (and have been fired in the past) if I didn't make plans, committed dates, and contracts with customers that managed scope, schedule & budget (see: all of professional program management). Please look up the papers on planning & quality & cost & schedule from Capers Jones. The textbook is literally titled "The Economics of Software Quality". Tom DeMarco's classic is "Controlling Software Projects". I'm trying to give you a starting point to see that it's not even my anecdotes, but repeatable studies that show this. Your examples are that requirements change, and it's hard. Of the few buildings I have built, the requirements changed drastically there in all cases, so I can only say that software engineering is not magically different. After decades of practice with software engineering my experience of planning lines up with the textbooks you can find on the topic, and not this blog post.