11 ms·

Microsoft Word for Windows 1.0 Postmortem (1989) [pdf]

235 points by pauldix 8y ago

pauldix 8y ago
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.
gheese 8y ago
Interesting how we drill in the idea that postmortems ought to be blame free. Not here.
- ams6110 8y ago
  Which isn't realistic in some cases. For example, if the postmortem determines that project management was lacking, that traces back to somebody, even if he or she isn't named.
  - tome 8y ago
    Can't you stop past blaming the project manage by analysing the reason he/she did something wrong?
    - saalweachter 8y ago
      To expound, if you focus too much on “Jeff did X wrong”, the take home message of the postmortem is “don’t be Jeff”. If you focus on “trying to solve X by Y failed because Z”, you have the more generally applicable message, “don’t do Y to solve X unless you can deal with Z”. Also keep in mind that Microsoft today is a robust corporation with many jealously defended fiefdoms; carefully picking the people to throw under the bus to protect your fiefdom and attack your internal competitors’ fiefdoms is an important skill set in such an environment. You could be seeing that in this postmortem, and that is exactly what people are trying to stop by keeping postmortems “blameless”.
  - nradov 8y ago
    But we have to look deeper. Project management doesn't exist in isolation. Any software development organization will typically have a project management office (PMO) with documented methodology, policies, procedures, templates, best practices, etc. If a particular project had poor project management then why did that happen? Did the PMO fail to provide the right resources? Is the hiring process for project managers faulty? Are we giving project managers the necessary training before assigning them to real projects? Occasionally individuals really are to blame. But organizations get better results when everyone assumes positive intent by individual employees and focuses on finding process problems.
antoineMoPa 8y ago
So much frustration could have been avoided by just using LaTeX.
- pjc50 8y ago
  Very different tool for different purposes. And it's never really been WYSIWYG.
  - antoineMoPa 8y ago
    (?) Both can be used for CVs, letters, lab reports, publications. My life was only simplified when I switched to LaTeX. WYSIWYGs are overrated.
    - pjc50 8y ago
      I keep my CV in Latex, and did my undergraduate thesis that way; but I'm very aware that for day to day non-maths work this is not a simple workflow and that most people would prefer a system in which they can see the effect of their changes immediately. (See the discussion in another comment about styles in word and how few people use them). WYSIWYG and DTP was the liberatory technology of the 80s and early 90s - suddenly everyone could produce documents with little training.
    - AnimalMuppet 8y ago
      Simplify your life further. Use Lyx (a frontend for LaTeX). It's pretty much WYSIWYG, but you're still using LaTeX.
- krylon 8y ago
  I do like LaTeX very much, but I do not think it is fair to expect the average person to learn LaTeX.
- pjmlp 8y ago
  I did my university project reports and the final dissertation in LaTeX. Since 2000 I never bothered to deal with it ever again.
shafte 8y ago
This is a great piece of software development history! Very interesting to see what things the industry seems to have improved on (somewhat) and what things we still struggle with. Things we have improved: - Developers are generally expected to be responsible for testing (and now operating) code. - Code reviews and ownership are common practice. - Distinctions between prototype/development/bugfixing stages are no longer strictly enforced. Things that we still struggle with: - Overspecialization/knowledge "siloing", and low bus factors generally. - Navigating the tradeoffs between re-using existing solutions vs. building your own.
- pjmlp 8y ago
  Code reviews and ownership are not as common practice as I would like them to be. Actually I can still count on how many projects there were actually part of the overall delivery process.
frou_dh 8y ago
It's wild that shops in the 80s were already taking application development more seriously than some shops are capable of doing in the present day.
- deleted 8y ago
  [deleted]
- pjc50 8y ago
  Hardly wild - I would say that as software has got easier with lower barrier to entry, development gets less and less "serious". I mean, how serious was the Apollo guidance computer project?
rusanu 8y ago
Was the post-mortem itself typed in Word?
ptaipale 8y ago
Reading this, it is interesting that Word for Windows 1.0 was usable at all. But I did use it quite a lot. It had problems, but generally, the "save often, each time with a different name" enabled one to get good results in editing documents.
namdnay 8y ago
Very interesting, thanks! Does anyone know what exactly the "programmer assistants" did? It sounds like a job that was left by the side of the road of technological progress
- deleted 8y ago
  [deleted]
- bklaasen 8y ago
  Thanks for spotting that. It's the first time I've come across the title. They seem to have been a combination of tester and sysadmin. Take a look at the table on pages 2 and 3 where you'll see 'PA' under the 'Position' heading. I've just started on the doc - where did you find the expansion of 'PA' into 'programmer assistant'? Only one of the 19 SDEs were female, whereas three of the nine PAs were. That's in line with the gender ratios I've seen in testing and development groups during my career. Testing is a feminised role, in line with its perceived low status. (I'm a (white cis male) tester, and I've always seem myself as a programmer assistant, as well as taking on extra tasks such as those falling under the 'PA' role here.)
  - bklaasen 8y ago
    Para 9, page 4
- deleted 8y ago
  [deleted]
sytelus 8y ago
This is quite a treasure trove of data for Word 1.0: - 55 man years - 38 man years by full time employees (FTEs) - 7000 LOC/yr code written per FTE - product + tools = 347 KLOC - 12,511 bugs, 9377 deemed fixable - 1197 bugs postponed (13% of that were fixable) - 247 bugs/yr fixed per FTE - 38 bugs/KLOC - Total 5 yrs (1st yr just 1 person, last yr had 13 max, other yrs had 10 avg) It is quite amazing that a young company allowed such a long running project and kept at it despite of many schedule misses for 5 years. This is now almost never observed even in resource rich mega corps. Also it seems developer productivity and bug count per KLOC has more or less remained same all these years. I haven't spent much time on researching this but if its true then I wonder what we gained out of improvements in languages and other development infrastructure? May be perhaps ability to scale to teams of 100s of developers per project totalling million KLOC? Interestingly World 1.0 team never went above 13 people despite of so many delays - may be because it was hard to scale using infrastructure available at the time (for example, no OOP)? Regardless the fact that average developer productivity in terms of KLOC and bugs/KLOC has remained fairly constant is very interesting.
- melling 8y ago
  Microsoft beat WordPerfect in the transition to Windows. This was the product that eventually killed WordPerfect and gave them a decades long monopoly in word processing that still exists. Lotus 123 suffered a similar fate against Excel.
  - tinus_hn 8y ago
    WordPerfect had stagnated and lacked features. That’s why it died.
    - melling 8y ago
      No, that’s not accurate. They took too long to get to Windows. Then Microsoft created the Office bundle and never looked back.
    - nradov 8y ago
      To some degree WordPerfect also failed due to a classic "Innovator's Dilemma" situation. They had a huge customer base of MS-DOS users and tried to keep them happy by maintaining a similar user experience in the Windows edition. And they were fairly successful it that goal, but the product ended up looking weird and counter intuitive to new users who were familiar with the standard Windows look and feel. The lesson is that sometimes you need to have the courage to disregard what existing customers want.
jmiserez 8y ago
I find the snippet on CRLF funny. Even Microsoft didn't like them! >In Opus paragraph marks are represented by two characters (carriage return-line feed) except for section marks which are only one character (chSect) and possibly other format files (Unix files with only line feeds and Mac files with only carriage returns). In Mac code all paragraphs end with a single character. Our model caused many problems and complicated code on top of the complications arising from being different from Mac Word.
- mdpopescu 8y ago
  I am pretty sure that the CRLF ending was inherited from CP/M.
  - mmastrac 8y ago
    Which, for those who don't know, inherited it down the chain from raw teletype machine baudot code (eg: see the videos by CuriousMarc on restoring early TTYs) - so it's 'technically correct'. Back then the machine could either feed a line OR return the carriage to the start. Not both!
    - mdpopescu 8y ago
      Man, I forgot about those! You're right, I actually used a teletype for about a year on a PDP-11 clone.
    - leoc 8y ago
      That distinction between carriage return and line feed is in turn a general feature of physical typewriter mechanisms, though even manual typewriters would give you an automatic line feed every time you returned the carriage: https://www.youtube.com/watch?v=r97JHr13T98 https://www.youtube.com/watch?v=r97JHr13T98 . Line feed could also be manually controlled by using the platen knobs on the sides of the platen (the big roller which the paper was fed onto).
cheschire 8y ago
I find it interesting that even though they knew that they were building a multi-platform product, they insisted on inheriting CRLF from DOS anyways, knowing full well that it created issues. That little decision he described as a failure painted a good picture for me.
- yqh 8y ago
  They weren't building a multi-platform product, and in fact he resents that so much Mac code was foisted on them.
pjc50 8y ago
The little sticker on the first page of the memo indicates that we're able to read this because it's part of the Comes V Microsoft antitrust litigation. See http://iowa.gotthefacts.org/ http://iowa.gotthefacts.org/ Perhaps a good time to remember not to put things in writing at work (this includes Slack) that you wouldn't want seen in exhibits for the prosecution. I browsed around randomly (the exhibits are untitled) and found http://iowa.gotthefacts.org/011607/0000/PX00697.pdf http://iowa.gotthefacts.org/011607/0000/PX00697.pdf : "we have sorted criticisms of Microsoft into three categories: lying, cheating, and arrogance" (to Ballmer) http://iowa.gotthefacts.org/011607/0000/PX00764.pdf http://iowa.gotthefacts.org/011607/0000/PX00764.pdf : angry letter from Borland http://iowa.gotthefacts.org/011607/0000/PX00859.pdf http://iowa.gotthefacts.org/011607/0000/PX00859.pdf : competitive analysis memo versus PenOS, perhaps the first company to produce what would be recognisable as an iPad ancestor. In 1991.
- deleted 8y ago
  [deleted]
- deleted 8y ago
  [deleted]
- HAL9000Ti 8y ago
  Fascinating, and I wasn't even close to exist yet
- dfee 8y ago
  Well, I’d love to learn more about PenOS, but Google seems to provide NSFW results. Anyone have a demo video? Edit: https://m.youtube.com/watch?v=x0XE08BjQDQ https://m.youtube.com/watch?v=x0XE08BjQDQ
  - pjc50 8y ago
    That was surprising ... perhaps "Penpoint OS" would be better. https://en.wikipedia.org/wiki/PenPoint_OS https://en.wikipedia.org/wiki/PenPoint_OS
  - deleted 8y ago
    [deleted]
krylon 8y ago
In Fred Moody's "I Sing The Body Electronic"[0], there is a passage where the author gets to read such postmortem documents and is surprised by the brutal honesty, but does not give any quotes. Now I see what he meant. [0] which I highly recommend, btw
- bklaasen 8y ago
  Thanks for the recommendation. I have to add G. Pascal Zachary's "Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" as another excellent look inside Microsoft's software development practices during the mid 1990s.
  - krylon 8y ago
    Thank you! That sounds like a fascinating read, I'll get right on it!
jasim 8y ago
Everything is different today, yet nothing is. A quote from the report: The methods of scheduling used were fatally flawed. A schedule should be considered a tool used to predict a ship date, it should not be considered a contract by development. Because there was so much pressure to meet the schedule, development got into a mode which Chris Mason refers to as "infinite defects". Developers get credit every time they can check a feature off, so they are more inclined to mark off their current feature and go on even though it really is not done. There was a prevailing attitude of the "testers will find it" when thinking about potential bugs in code being developed. In many cases they did find it, and that is what caused our stabilization phase to grow from the expected 3 months (which is a pretty random number anyway), to 13 months. Because every task was cut to the bare minimum, performance work that should have been done was neglected until the very end of the project, reducing what we could do in a reasonable amount of time.
- spolsky 8y ago
  A member of that team told me that for much of the project the implementation of the function to calculate the height of a line of text, which is a very complication operation involving fonts, sub- and super-scripts, etc., was implemented as "return 12;" (that was the entire body of the function) and it was marked as "DONE". With a bug of course but we can fix the bugs later
  - dehrmann 8y ago
    > Calculat[ing] the height of a line of text...is a very complicat[ed] operation. So true. And width, and how many characters fit on a line. The list goes on.
deleted 8y ago
[deleted]
orf 8y ago
Shout out to Peter Jackson, a Junior member of the team who was made both Technical and Project lead by Jeff. Imagine that: one day Jeff bounces in and decrees you, an inexperienced junior dev, now have to do not one but two lead jobs at once.
- quietbritishjim 8y ago
  Although that bit is written in the third person, Peter Jackson is the report author (according to the second page). That doesn't change your point but it does add a bit of flavour to some of the text.
roland35 8y ago
One interesting thought, 7 KLOC per FTE/year works out to about 28 lines of code per work day! It does not seem like much until you realize each line of code requires integration, testing, bug fixing, and documentation if you are lucky! I think it would be good for more organizations to use data like this to set realistic schedules because it always takes longer than you would think you need. Luckily with tools like git this is much easier.
- merb 8y ago
  I doubt that they did integration testing (automated) back in the day.
- robaato 8y ago
  https://successfulsoftware.net/2017/02/10/how-much-code-can-a-coder-code/ https://successfulsoftware.net/2017/02/10/how-much-code-can-...
iheartpotatoes 8y ago
Still better than Word 2017. ;) I mean, come on, it still screws up fonts on macOS and it's 30+ years old?!?
Tempest1981 8y ago
Was Bryan's illness related to the stressful environment? If so, interesting that he later returned to be Project Lead, esp when he was "better, but not well"
deleted 8y ago
[deleted]
Tempest1981 8y ago
"Peter continually experimented with strategies to improve morale ... But the amount of administrative overhead ... and the distractions of going from one to the next probably did more damage than good." I know this feeling - watching someone try to treat the symptom (stress, burnout), without addressing the root cause. But knowing that the root cause is a systematic issue (very hard to fix), what can a project lead do to help morale and the team?
userbinator 8y ago
MS released the source code for version 1.1a of this application: http://www.computerhistory.org/atchm/microsoft-word-for-windows-1-1a-source-code/ http://www.computerhistory.org/atchm/microsoft-word-for-wind... (You can find copies scattered around GitHub and elsewhere too.)
boudewijnrempt 8y ago
I wonder how this pdf was produced... Word for Windows 1.0 wouldn't have been able to do those tables.

235 points by pauldix 8y ago

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.

gheese 8y ago

Interesting how we drill in the idea that postmortems ought to be blame free. Not here.

ams6110 8y ago
Which isn't realistic in some cases. For example, if the postmortem determines that project management was lacking, that traces back to somebody, even if he or she isn't named.
- tome 8y ago
  Can't you stop past blaming the project manage by analysing the reason he/she did something wrong?
  - saalweachter 8y ago
    To expound, if you focus too much on “Jeff did X wrong”, the take home message of the postmortem is “don’t be Jeff”. If you focus on “trying to solve X by Y failed because Z”, you have the more generally applicable message, “don’t do Y to solve X unless you can deal with Z”. Also keep in mind that Microsoft today is a robust corporation with many jealously defended fiefdoms; carefully picking the people to throw under the bus to protect your fiefdom and attack your internal competitors’ fiefdoms is an important skill set in such an environment. You could be seeing that in this postmortem, and that is exactly what people are trying to stop by keeping postmortems “blameless”.
- nradov 8y ago
  But we have to look deeper. Project management doesn't exist in isolation. Any software development organization will typically have a project management office (PMO) with documented methodology, policies, procedures, templates, best practices, etc. If a particular project had poor project management then why did that happen? Did the PMO fail to provide the right resources? Is the hiring process for project managers faulty? Are we giving project managers the necessary training before assigning them to real projects? Occasionally individuals really are to blame. But organizations get better results when everyone assumes positive intent by individual employees and focuses on finding process problems.

antoineMoPa 8y ago

So much frustration could have been avoided by just using LaTeX.

pjc50 8y ago
Very different tool for different purposes. And it's never really been WYSIWYG.
- antoineMoPa 8y ago
  (?) Both can be used for CVs, letters, lab reports, publications. My life was only simplified when I switched to LaTeX. WYSIWYGs are overrated.
  - pjc50 8y ago
    I keep my CV in Latex, and did my undergraduate thesis that way; but I'm very aware that for day to day non-maths work this is not a simple workflow and that most people would prefer a system in which they can see the effect of their changes immediately. (See the discussion in another comment about styles in word and how few people use them). WYSIWYG and DTP was the liberatory technology of the 80s and early 90s - suddenly everyone could produce documents with little training.
  - AnimalMuppet 8y ago
    Simplify your life further. Use Lyx (a frontend for LaTeX). It's pretty much WYSIWYG, but you're still using LaTeX.
krylon 8y ago
I do like LaTeX very much, but I do not think it is fair to expect the average person to learn LaTeX.
pjmlp 8y ago
I did my university project reports and the final dissertation in LaTeX. Since 2000 I never bothered to deal with it ever again.

shafte 8y ago

This is a great piece of software development history! Very interesting to see what things the industry seems to have improved on (somewhat) and what things we still struggle with. Things we have improved: - Developers are generally expected to be responsible for testing (and now operating) code. - Code reviews and ownership are common practice. - Distinctions between prototype/development/bugfixing stages are no longer strictly enforced. Things that we still struggle with: - Overspecialization/knowledge "siloing", and low bus factors generally. - Navigating the tradeoffs between re-using existing solutions vs. building your own.

pjmlp 8y ago
Code reviews and ownership are not as common practice as I would like them to be. Actually I can still count on how many projects there were actually part of the overall delivery process.

frou_dh 8y ago

It's wild that shops in the 80s were already taking application development more seriously than some shops are capable of doing in the present day.

deleted 8y ago
[deleted]
pjc50 8y ago
Hardly wild - I would say that as software has got easier with lower barrier to entry, development gets less and less "serious". I mean, how serious was the Apollo guidance computer project?

rusanu 8y ago

Was the post-mortem itself typed in Word?

ptaipale 8y ago

Reading this, it is interesting that Word for Windows 1.0 was usable at all. But I did use it quite a lot. It had problems, but generally, the "save often, each time with a different name" enabled one to get good results in editing documents.

namdnay 8y ago

Very interesting, thanks! Does anyone know what exactly the "programmer assistants" did? It sounds like a job that was left by the side of the road of technological progress

deleted 8y ago
[deleted]
bklaasen 8y ago
Thanks for spotting that. It's the first time I've come across the title. They seem to have been a combination of tester and sysadmin. Take a look at the table on pages 2 and 3 where you'll see 'PA' under the 'Position' heading. I've just started on the doc - where did you find the expansion of 'PA' into 'programmer assistant'? Only one of the 19 SDEs were female, whereas three of the nine PAs were. That's in line with the gender ratios I've seen in testing and development groups during my career. Testing is a feminised role, in line with its perceived low status. (I'm a (white cis male) tester, and I've always seem myself as a programmer assistant, as well as taking on extra tasks such as those falling under the 'PA' role here.)
- bklaasen 8y ago
  Para 9, page 4
deleted 8y ago
[deleted]

sytelus 8y ago

This is quite a treasure trove of data for Word 1.0: - 55 man years - 38 man years by full time employees (FTEs) - 7000 LOC/yr code written per FTE - product + tools = 347 KLOC - 12,511 bugs, 9377 deemed fixable - 1197 bugs postponed (13% of that were fixable) - 247 bugs/yr fixed per FTE - 38 bugs/KLOC - Total 5 yrs (1st yr just 1 person, last yr had 13 max, other yrs had 10 avg) It is quite amazing that a young company allowed such a long running project and kept at it despite of many schedule misses for 5 years. This is now almost never observed even in resource rich mega corps. Also it seems developer productivity and bug count per KLOC has more or less remained same all these years. I haven't spent much time on researching this but if its true then I wonder what we gained out of improvements in languages and other development infrastructure? May be perhaps ability to scale to teams of 100s of developers per project totalling million KLOC? Interestingly World 1.0 team never went above 13 people despite of so many delays - may be because it was hard to scale using infrastructure available at the time (for example, no OOP)? Regardless the fact that average developer productivity in terms of KLOC and bugs/KLOC has remained fairly constant is very interesting.

melling 8y ago
Microsoft beat WordPerfect in the transition to Windows. This was the product that eventually killed WordPerfect and gave them a decades long monopoly in word processing that still exists. Lotus 123 suffered a similar fate against Excel.
- tinus_hn 8y ago
  WordPerfect had stagnated and lacked features. That’s why it died.
  - melling 8y ago
    No, that’s not accurate. They took too long to get to Windows. Then Microsoft created the Office bundle and never looked back.
  - nradov 8y ago
    To some degree WordPerfect also failed due to a classic "Innovator's Dilemma" situation. They had a huge customer base of MS-DOS users and tried to keep them happy by maintaining a similar user experience in the Windows edition. And they were fairly successful it that goal, but the product ended up looking weird and counter intuitive to new users who were familiar with the standard Windows look and feel. The lesson is that sometimes you need to have the courage to disregard what existing customers want.

jmiserez 8y ago

I find the snippet on CRLF funny. Even Microsoft didn't like them! >In Opus paragraph marks are represented by two characters (carriage return-line feed) except for section marks which are only one character (chSect) and possibly other format files (Unix files with only line feeds and Mac files with only carriage returns). In Mac code all paragraphs end with a single character. Our model caused many problems and complicated code on top of the complications arising from being different from Mac Word.

mdpopescu 8y ago
I am pretty sure that the CRLF ending was inherited from CP/M.
- mmastrac 8y ago
  Which, for those who don't know, inherited it down the chain from raw teletype machine baudot code (eg: see the videos by CuriousMarc on restoring early TTYs) - so it's 'technically correct'. Back then the machine could either feed a line OR return the carriage to the start. Not both!
  - mdpopescu 8y ago
    Man, I forgot about those! You're right, I actually used a teletype for about a year on a PDP-11 clone.
  - leoc 8y ago
    That distinction between carriage return and line feed is in turn a general feature of physical typewriter mechanisms, though even manual typewriters would give you an automatic line feed every time you returned the carriage: https://www.youtube.com/watch?v=r97JHr13T98 https://www.youtube.com/watch?v=r97JHr13T98 . Line feed could also be manually controlled by using the platen knobs on the sides of the platen (the big roller which the paper was fed onto).

cheschire 8y ago

I find it interesting that even though they knew that they were building a multi-platform product, they insisted on inheriting CRLF from DOS anyways, knowing full well that it created issues. That little decision he described as a failure painted a good picture for me.

yqh 8y ago
They weren't building a multi-platform product, and in fact he resents that so much Mac code was foisted on them.

pjc50 8y ago

The little sticker on the first page of the memo indicates that we're able to read this because it's part of the Comes V Microsoft antitrust litigation. See http://iowa.gotthefacts.org/ http://iowa.gotthefacts.org/ Perhaps a good time to remember not to put things in writing at work (this includes Slack) that you wouldn't want seen in exhibits for the prosecution. I browsed around randomly (the exhibits are untitled) and found http://iowa.gotthefacts.org/011607/0000/PX00697.pdf http://iowa.gotthefacts.org/011607/0000/PX00697.pdf : "we have sorted criticisms of Microsoft into three categories: lying, cheating, and arrogance" (to Ballmer) http://iowa.gotthefacts.org/011607/0000/PX00764.pdf http://iowa.gotthefacts.org/011607/0000/PX00764.pdf : angry letter from Borland http://iowa.gotthefacts.org/011607/0000/PX00859.pdf http://iowa.gotthefacts.org/011607/0000/PX00859.pdf : competitive analysis memo versus PenOS, perhaps the first company to produce what would be recognisable as an iPad ancestor. In 1991.

deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
HAL9000Ti 8y ago
Fascinating, and I wasn't even close to exist yet
dfee 8y ago
Well, I’d love to learn more about PenOS, but Google seems to provide NSFW results. Anyone have a demo video? Edit: https://m.youtube.com/watch?v=x0XE08BjQDQ https://m.youtube.com/watch?v=x0XE08BjQDQ
- pjc50 8y ago
  That was surprising ... perhaps "Penpoint OS" would be better. https://en.wikipedia.org/wiki/PenPoint_OS https://en.wikipedia.org/wiki/PenPoint_OS
- deleted 8y ago
  [deleted]

krylon 8y ago

In Fred Moody's "I Sing The Body Electronic"[0], there is a passage where the author gets to read such postmortem documents and is surprised by the brutal honesty, but does not give any quotes. Now I see what he meant. [0] which I highly recommend, btw

bklaasen 8y ago
Thanks for the recommendation. I have to add G. Pascal Zachary's "Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" as another excellent look inside Microsoft's software development practices during the mid 1990s.
- krylon 8y ago
  Thank you! That sounds like a fascinating read, I'll get right on it!

jasim 8y ago

Everything is different today, yet nothing is. A quote from the report: The methods of scheduling used were fatally flawed. A schedule should be considered a tool used to predict a ship date, it should not be considered a contract by development. Because there was so much pressure to meet the schedule, development got into a mode which Chris Mason refers to as "infinite defects". Developers get credit every time they can check a feature off, so they are more inclined to mark off their current feature and go on even though it really is not done. There was a prevailing attitude of the "testers will find it" when thinking about potential bugs in code being developed. In many cases they did find it, and that is what caused our stabilization phase to grow from the expected 3 months (which is a pretty random number anyway), to 13 months. Because every task was cut to the bare minimum, performance work that should have been done was neglected until the very end of the project, reducing what we could do in a reasonable amount of time.

spolsky 8y ago
A member of that team told me that for much of the project the implementation of the function to calculate the height of a line of text, which is a very complication operation involving fonts, sub- and super-scripts, etc., was implemented as "return 12;" (that was the entire body of the function) and it was marked as "DONE". With a bug of course but we can fix the bugs later
- dehrmann 8y ago
  > Calculat[ing] the height of a line of text...is a very complicat[ed] operation. So true. And width, and how many characters fit on a line. The list goes on.

deleted 8y ago

[deleted]

orf 8y ago

Shout out to Peter Jackson, a Junior member of the team who was made both Technical and Project lead by Jeff. Imagine that: one day Jeff bounces in and decrees you, an inexperienced junior dev, now have to do not one but two lead jobs at once.

quietbritishjim 8y ago
Although that bit is written in the third person, Peter Jackson is the report author (according to the second page). That doesn't change your point but it does add a bit of flavour to some of the text.

roland35 8y ago

One interesting thought, 7 KLOC per FTE/year works out to about 28 lines of code per work day! It does not seem like much until you realize each line of code requires integration, testing, bug fixing, and documentation if you are lucky! I think it would be good for more organizations to use data like this to set realistic schedules because it always takes longer than you would think you need. Luckily with tools like git this is much easier.

merb 8y ago
I doubt that they did integration testing (automated) back in the day.
robaato 8y ago
https://successfulsoftware.net/2017/02/10/how-much-code-can-a-coder-code/ https://successfulsoftware.net/2017/02/10/how-much-code-can-...

iheartpotatoes 8y ago

Still better than Word 2017. ;) I mean, come on, it still screws up fonts on macOS and it's 30+ years old?!?

Tempest1981 8y ago

Was Bryan's illness related to the stressful environment? If so, interesting that he later returned to be Project Lead, esp when he was "better, but not well"

deleted 8y ago

[deleted]

Tempest1981 8y ago

"Peter continually experimented with strategies to improve morale ... But the amount of administrative overhead ... and the distractions of going from one to the next probably did more damage than good." I know this feeling - watching someone try to treat the symptom (stress, burnout), without addressing the root cause. But knowing that the root cause is a systematic issue (very hard to fix), what can a project lead do to help morale and the team?

userbinator 8y ago

MS released the source code for version 1.1a of this application: http://www.computerhistory.org/atchm/microsoft-word-for-windows-1-1a-source-code/ http://www.computerhistory.org/atchm/microsoft-word-for-wind... (You can find copies scattered around GitHub and elsewhere too.)

boudewijnrempt 8y ago

I wonder how this pdf was produced... Word for Windows 1.0 wouldn't have been able to do those tables.