5 ms·

I thought this was a super interesting read. Despite the year, so many of the problems are the exact same. This project was massively late. Development went on

I thought this was a super interesting read. Despite the year, so many of the problems are the exact same. This project was massively late. Development went on for five years and they always thought they were a year or less away from shipping. My favorite section is on Schedule Analysis. Particularly this quote: "A schedule should be considered a tool to predict a ship date, it should not be considered a contract by development."

ivraatiems 8y ago
In a similar vein, my favorite quote so far: "The idea that a schedule is God leads to infinite defects, as explained above. Also, the belief that a schedule must be ambitious so that the development team will work hard is severely misguided." (bottom of page 12) Those two sentences, written almost 30 years ago now, pretty much sum up my perspective on how software projects are scheduled. I think plenty of companies have yet to learn this lesson. In fact, so many of the things in this document reflect things many organizations, to my knowledge, still struggle with today. I'm also just amazed at how deep this goes and how personal it is. Its creation must have upset a lot of people.
- triggercut 8y ago
  I often find myself reading 'old' (15+ years) books on planning, Government and NGO working group papers on Major capital projects / Project Management (PM), journal articles on various PM topics, and sometimes it feels as if very little material progress has been made in the discipline since the 70's. If anything, our propensity for relying on technology to 'take care' of particular parts in some cases takes us backwards. As someone who schedules and oversees complex programes and their governance for (most of) their living, a few observations that are common across all domains: - We are still very bad at understanding the total scope of work (whether it has been done before or not) - We are still very bad at understanding the work that must be done to deliver that scope (whether it has been done before or not) - We are still very bad at understanding how long it takes to do the work, especially if the work is more cerebral (whether it has been done before or not) - We still think we can predict the future with certainty with enough information - Things are becoming more complex and (perhaps) more uncertain - We are still bad at making decisions and usually avoid them, or make them without giving proper thought to their consequences A schedule's value is not just in '''predicting''' an end date. A schedule primarily does three things: Past / Status / Forecast - It records work/effort in the past - It gives you the status against plan - It forecasts the likely times when future work will take place and the amount of work left to complete the project This in term serves multiple project stakeholders in different ways. Leaders want to be able to budget, because the cost of money can be more or less expensive at different times. The cost of resources can be more or less expensive at different times. Workers want to know what they should be doing and how long they have to do it. Managers need to balance limited resources and (re)direct effort. Even with risk and resource loaded probabilistic scheduling with tens of thousands of montecarlo iterations, your actual path is still only one of those possible realities. But as in all models, there are sensitivities and if properly constructed understanding the sensitivities in the precedence graph is sometimes as important as calculating the critical path.
- peatfreak 8y ago
  > Its creation must have upset a lot of people. Indeed. About the only difference in essence between this and well written contemporary post mortems is that individuals are named. In other words, it's not a "blameless" post mortem; on the contrary, the knives come out and people are savaged by name.
  - DannyBee 8y ago
    Which actually takes away from it in several places, IMHO. If you read the savagery about the standard dialog stuff, 1. The author inserts pointless opinion about the likely success or failure of that project 2. The author may have been very wrong? I am not a Microsoft archeologist, but it looks like the goal of having significant sets of standard dialogs as a shared library was in fact, wildly successful? In a lot of ways, it was a bright spot in programs that fucked the UI up for everything else - the standard dialogs were so standard and good that when java and other things had their own file/etc dialogs, everyone noticed and complained.
    - slededit 8y ago
      SDM dialogs live even today in the bowls of office Apps. Although it has since been supplanted by at least two “hot new things” since then. Last I heard there wast talk of moving to React. Never does a new technology fully replace the old.
      - tome 8y ago
        SDM = standard dialog manager, presumably https://docs.microsoft.com/en-us/windows/desktop/WinAuto/appendix-b--standard-dialog-manager-support https://docs.microsoft.com/en-us/windows/desktop/WinAuto/app...
- gaius 8y ago
  a schedule must be ambitious so that the development team will work hard is severely misguided Several times in my career I have seen a CEO shamelessly say well done team another record breaking year but we didn’t meet our “stretch goals” so there will be no bonuses (for you). Managers occupy this weird world in which their staff is clever enough to work on advanced technology but too stupid to see through such transparent deception.
  - maxxxxx 8y ago
    Well, it works for them. Reminds me a little of communist states. Everybody knew that the official information was bullshit but it still kept going.
- quietbritishjim 8y ago
  The idea that a schedule is God leads to infinite defects A great example of this is recounted by Joel Spolsky [1] who was a project manager for the early Excel team (but presumably the problems in the Word team became legend): [In] the very first version of Microsoft Word for Windows ... the project managers had been so insistent on keeping to the “schedule” that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote “return 12;” and waited for the bug report to come in about how his function is not always correct. The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as “infinite defects methodology”. [1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
  - richard_todd 8y ago
    Immediately brings to mind: The first book I read on TDD recommended writing "return 12" and waiting for a test that fails. So I guess PR/marketing could say Microsoft pioneered an early form of TDD in WinWord, combining it with the power of pair-collaboration between a developer and a tester. Just one more in a long line of MS innovations.
    - dpark 8y ago
      Your book seems to be selling a peculiar flavor of TDD. Typical TDD says you write the failing test first. You don’t wait for it to appear after writing your broken code.
      - richard_todd 8y ago
        It's not that it is the first thing written--it's that it recommends writing broken code like "return 12" until a test knocks it down. I think that book (it's been 15 years!) went through a currency-exchange example, but you know how they go: write your first test "The sqrt of 4 is 2".. make it pass "return 2" etc. In all cases, the person writing the code knows it won't stand, but they do it anyway. That was the parallel which prompted my comment.
christophilus 8y ago
“We started out by building a prototype, and on top of that prototype we tried to build a product.” Sums up many projects early in my career. I think this should be a must read for anyone whose job involves managing a software project. I’ve personally witnessed every major mistake listed in the first twelve pages.
- dpark 8y ago
  This is why “build one to throw away” is an anti-pattern. No one ever throws it away, so building it like it’s a prototype means prototype code eventually makes it to production.

ivraatiems 8y ago

In a similar vein, my favorite quote so far: "The idea that a schedule is God leads to infinite defects, as explained above. Also, the belief that a schedule must be ambitious so that the development team will work hard is severely misguided." (bottom of page 12) Those two sentences, written almost 30 years ago now, pretty much sum up my perspective on how software projects are scheduled. I think plenty of companies have yet to learn this lesson. In fact, so many of the things in this document reflect things many organizations, to my knowledge, still struggle with today. I'm also just amazed at how deep this goes and how personal it is. Its creation must have upset a lot of people.

triggercut 8y ago
I often find myself reading 'old' (15+ years) books on planning, Government and NGO working group papers on Major capital projects / Project Management (PM), journal articles on various PM topics, and sometimes it feels as if very little material progress has been made in the discipline since the 70's. If anything, our propensity for relying on technology to 'take care' of particular parts in some cases takes us backwards. As someone who schedules and oversees complex programes and their governance for (most of) their living, a few observations that are common across all domains: - We are still very bad at understanding the total scope of work (whether it has been done before or not) - We are still very bad at understanding the work that must be done to deliver that scope (whether it has been done before or not) - We are still very bad at understanding how long it takes to do the work, especially if the work is more cerebral (whether it has been done before or not) - We still think we can predict the future with certainty with enough information - Things are becoming more complex and (perhaps) more uncertain - We are still bad at making decisions and usually avoid them, or make them without giving proper thought to their consequences A schedule's value is not just in '''predicting''' an end date. A schedule primarily does three things: Past / Status / Forecast - It records work/effort in the past - It gives you the status against plan - It forecasts the likely times when future work will take place and the amount of work left to complete the project This in term serves multiple project stakeholders in different ways. Leaders want to be able to budget, because the cost of money can be more or less expensive at different times. The cost of resources can be more or less expensive at different times. Workers want to know what they should be doing and how long they have to do it. Managers need to balance limited resources and (re)direct effort. Even with risk and resource loaded probabilistic scheduling with tens of thousands of montecarlo iterations, your actual path is still only one of those possible realities. But as in all models, there are sensitivities and if properly constructed understanding the sensitivities in the precedence graph is sometimes as important as calculating the critical path.
peatfreak 8y ago
> Its creation must have upset a lot of people. Indeed. About the only difference in essence between this and well written contemporary post mortems is that individuals are named. In other words, it's not a "blameless" post mortem; on the contrary, the knives come out and people are savaged by name.
- DannyBee 8y ago
  Which actually takes away from it in several places, IMHO. If you read the savagery about the standard dialog stuff, 1. The author inserts pointless opinion about the likely success or failure of that project 2. The author may have been very wrong? I am not a Microsoft archeologist, but it looks like the goal of having significant sets of standard dialogs as a shared library was in fact, wildly successful? In a lot of ways, it was a bright spot in programs that fucked the UI up for everything else - the standard dialogs were so standard and good that when java and other things had their own file/etc dialogs, everyone noticed and complained.
  - slededit 8y ago
    SDM dialogs live even today in the bowls of office Apps. Although it has since been supplanted by at least two “hot new things” since then. Last I heard there wast talk of moving to React. Never does a new technology fully replace the old.
    - tome 8y ago
      SDM = standard dialog manager, presumably https://docs.microsoft.com/en-us/windows/desktop/WinAuto/appendix-b--standard-dialog-manager-support https://docs.microsoft.com/en-us/windows/desktop/WinAuto/app...
gaius 8y ago
a schedule must be ambitious so that the development team will work hard is severely misguided Several times in my career I have seen a CEO shamelessly say well done team another record breaking year but we didn’t meet our “stretch goals” so there will be no bonuses (for you). Managers occupy this weird world in which their staff is clever enough to work on advanced technology but too stupid to see through such transparent deception.
- maxxxxx 8y ago
  Well, it works for them. Reminds me a little of communist states. Everybody knew that the official information was bullshit but it still kept going.
quietbritishjim 8y ago
The idea that a schedule is God leads to infinite defects A great example of this is recounted by Joel Spolsky [1] who was a project manager for the early Excel team (but presumably the problems in the Word team became legend): [In] the very first version of Microsoft Word for Windows ... the project managers had been so insistent on keeping to the “schedule” that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote “return 12;” and waited for the bug report to come in about how his function is not always correct. The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as “infinite defects methodology”. [1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
- richard_todd 8y ago
  Immediately brings to mind: The first book I read on TDD recommended writing "return 12" and waiting for a test that fails. So I guess PR/marketing could say Microsoft pioneered an early form of TDD in WinWord, combining it with the power of pair-collaboration between a developer and a tester. Just one more in a long line of MS innovations.
  - dpark 8y ago
    Your book seems to be selling a peculiar flavor of TDD. Typical TDD says you write the failing test first. You don’t wait for it to appear after writing your broken code.
    - richard_todd 8y ago
      It's not that it is the first thing written--it's that it recommends writing broken code like "return 12" until a test knocks it down. I think that book (it's been 15 years!) went through a currency-exchange example, but you know how they go: write your first test "The sqrt of 4 is 2".. make it pass "return 2" etc. In all cases, the person writing the code knows it won't stand, but they do it anyway. That was the parallel which prompted my comment.

christophilus 8y ago

“We started out by building a prototype, and on top of that prototype we tried to build a product.” Sums up many projects early in my career. I think this should be a must read for anyone whose job involves managing a software project. I’ve personally witnessed every major mistake listed in the first twelve pages.

dpark 8y ago
This is why “build one to throw away” is an anti-pattern. No one ever throws it away, so building it like it’s a prototype means prototype code eventually makes it to production.