3 ms·

"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

"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.
    - codemac 6y ago
      Great response, thank you! It seems I'm rubbing you the wrong way, or not understanding you well enough to respond in a way that encourages conversation, and that's crap. I'm sorry. > 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." This article must be taken in the context of his research in general. If you're optimizing for speed of initial delivery, rather than TCO, then any method with less planning delivers faster and costs less. However, if you assume your software lasts longer than ~year (as pointed out in my initial reference, and his much larger work "The Economics of Software Quality") then they perform much worse. The actual payoffs in most of his research is around 8 months of development. Being "quick" is basically a jab from Jones about agile project quality. > You're not even willing to consider that planning too far ahead can waste time and that planning does not optimize for speed. I'm willing to consider it, I think. My experience has shown the opposite for any project involving more than 1 person that a customer uses for more than a year. The research I can find shows me the same. Most projects I embark on tend to live in the market for longer than a year, and thus quality, TCO, and delivering on time matter. I guess I don't see how you manage a team, a project, a customer, or investors where you need to hire people based on work you need to do, if you're only planning out a few weeks at a time. I don't see any case where you're going to get VC funding, exec sponsorship, etc (i.e. manage the risk and expectations of capital) by saying "we'll see where we are in two weeks". This is where I start to fall into saying things about professionalism, as to me the difference between a professional and an amateur is exactly this capital and risk management.

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.
  - codemac 6y ago
    Great response, thank you! It seems I'm rubbing you the wrong way, or not understanding you well enough to respond in a way that encourages conversation, and that's crap. I'm sorry. > 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." This article must be taken in the context of his research in general. If you're optimizing for speed of initial delivery, rather than TCO, then any method with less planning delivers faster and costs less. However, if you assume your software lasts longer than ~year (as pointed out in my initial reference, and his much larger work "The Economics of Software Quality") then they perform much worse. The actual payoffs in most of his research is around 8 months of development. Being "quick" is basically a jab from Jones about agile project quality. > You're not even willing to consider that planning too far ahead can waste time and that planning does not optimize for speed. I'm willing to consider it, I think. My experience has shown the opposite for any project involving more than 1 person that a customer uses for more than a year. The research I can find shows me the same. Most projects I embark on tend to live in the market for longer than a year, and thus quality, TCO, and delivering on time matter. I guess I don't see how you manage a team, a project, a customer, or investors where you need to hire people based on work you need to do, if you're only planning out a few weeks at a time. I don't see any case where you're going to get VC funding, exec sponsorship, etc (i.e. manage the risk and expectations of capital) by saying "we'll see where we are in two weeks". This is where I start to fall into saying things about professionalism, as to me the difference between a professional and an amateur is exactly this capital and risk management.