"A schedule should be considered a tool to predict a ship date, it should not be considered a contract by development."
"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.
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.
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.
Never does a new technology fully replace the old.
https://docs.microsoft.com/en-us/windows/desktop/WinAuto/app...
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.
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-s...
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.
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.