4 ms·

> 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 def

> 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.
  - tchaffee 6y ago
    And after decades of experience myself I've seen the vast majority of plans become useless the further out they try to predict the future. I guess we'll have to agree to disagree about the value of learning by actually starting to build the new thing that no one has ever built before. Plan away if that suits you. I'll be building and learning about the domain in the meantime.
    - codemac 6y ago
      Who said you can't learn? I'm not understanding your point there. Is planning an activity that removes learning? I'm not claiming anything that's not well understood: https://ieeexplore.ieee.org/author/38632866300 https://ieeexplore.ieee.org/author/38632866300 Planning upfront takes less time than not planning up front, in all cases. You can plan to do a prototype, you can change your plan later, the activity of planning itself produces clarity. Reducing the argument to "planning away" is the same as me saying you're "flailing around like an amateur". It's not what you're saying though, so I wish you'd see this thread as a discussion rather than something to win with gotchas.
      - tchaffee 6y ago
        > Who said you can't learn? Exactly. You could learn about when and how to be more efficient when planning isn't called for. > Planning upfront takes less time than not planning up front, in all cases. It does not. > you can change your plan later, That costs time and money. Maintaining and changing a plan does not come for free. The more complex and further out your plan reaches, the more you'll have to change it. > the activity of planning itself produces clarity. Yes it does. And sometimes the activity of building a prototype produces more clarity than a plan. > I'm not claiming anything that's not well understood. : https://ieeexplore.ieee.org/author/38632866300 https://ieeexplore.ieee.org/author/38632866300 I like Capers Jones too. His recommendations are not the silver bullet you are treating them as. He sells software used for estimating, measuring, and planning... so of course he's not entirely unbiased. A lot of what he does applies very well to large organizations where large and frequent pivots are nowhere near as frequent as when working for a startup while exploring the features of something that is not evolutionary, but revolutionary. Check out this article where Capers Jones shows that Agile is one of the quickest and cheapest methodologies out there. https://www.infoq.com/articles/evaluating-agile-software-methodologies/ https://www.infoq.com/articles/evaluating-agile-software-met... And where he concludes "Overall the Agile family and the methods that emphasize speed have achieved their goal, and they are fairly quick. The methods that emphasize quality such as TSP, RUP, and CMMI 5 have also achieved their goals, and deliver very few defects. No single method appears to be a universal panacea that can be successful on every size and kind of software application." Huh. > I wish you'd see this thread as a discussion You're not even willing to consider that planning too far ahead can waste time and that planning does not optimize for speed. You are giving absolutes like "in all cases". If you want a discussion then you have to be willing to learn yourself. In my experience there are times when planning is essential. And times when planning, especially out more than a few weeks, is a waste of time. If you want to trade tips, great. If you want to continue to insist planning is an absolute, no thanks.

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.
- tchaffee 6y ago
  And after decades of experience myself I've seen the vast majority of plans become useless the further out they try to predict the future. I guess we'll have to agree to disagree about the value of learning by actually starting to build the new thing that no one has ever built before. Plan away if that suits you. I'll be building and learning about the domain in the meantime.
  - codemac 6y ago
    Who said you can't learn? I'm not understanding your point there. Is planning an activity that removes learning? I'm not claiming anything that's not well understood: https://ieeexplore.ieee.org/author/38632866300 https://ieeexplore.ieee.org/author/38632866300 Planning upfront takes less time than not planning up front, in all cases. You can plan to do a prototype, you can change your plan later, the activity of planning itself produces clarity. Reducing the argument to "planning away" is the same as me saying you're "flailing around like an amateur". It's not what you're saying though, so I wish you'd see this thread as a discussion rather than something to win with gotchas.
    - tchaffee 6y ago
      > Who said you can't learn? Exactly. You could learn about when and how to be more efficient when planning isn't called for. > Planning upfront takes less time than not planning up front, in all cases. It does not. > you can change your plan later, That costs time and money. Maintaining and changing a plan does not come for free. The more complex and further out your plan reaches, the more you'll have to change it. > the activity of planning itself produces clarity. Yes it does. And sometimes the activity of building a prototype produces more clarity than a plan. > I'm not claiming anything that's not well understood. : https://ieeexplore.ieee.org/author/38632866300 https://ieeexplore.ieee.org/author/38632866300 I like Capers Jones too. His recommendations are not the silver bullet you are treating them as. He sells software used for estimating, measuring, and planning... so of course he's not entirely unbiased. A lot of what he does applies very well to large organizations where large and frequent pivots are nowhere near as frequent as when working for a startup while exploring the features of something that is not evolutionary, but revolutionary. Check out this article where Capers Jones shows that Agile is one of the quickest and cheapest methodologies out there. https://www.infoq.com/articles/evaluating-agile-software-methodologies/ https://www.infoq.com/articles/evaluating-agile-software-met... And where he concludes "Overall the Agile family and the methods that emphasize speed have achieved their goal, and they are fairly quick. The methods that emphasize quality such as TSP, RUP, and CMMI 5 have also achieved their goals, and deliver very few defects. No single method appears to be a universal panacea that can be successful on every size and kind of software application." Huh. > I wish you'd see this thread as a discussion You're not even willing to consider that planning too far ahead can waste time and that planning does not optimize for speed. You are giving absolutes like "in all cases". If you want a discussion then you have to be willing to learn yourself. In my experience there are times when planning is essential. And times when planning, especially out more than a few weeks, is a waste of time. If you want to trade tips, great. If you want to continue to insist planning is an absolute, no thanks.