
Microsoft Word for Windows 1.0 Postmortem (1989) [pdf] - pauldix
http://antitrust.slated.org/www.iowaconsumercase.org/011607/8000/PX08875.pdf
======
sytelus
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
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
WordPerfect had stagnated and lacked features. That’s why it died.

~~~
nradov
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.

~~~
dpark
> _The lesson is that sometimes you need to have the courage to disregard what
> existing customers want._

The problem is that this can kill you, too. If you abandon your current
customers, chances are that they’ll choose a new solution because you’ve taken
away their “easy path” upgrade and also pissed them off. You also send a
message to your potential new customers that you won’t care about _them_ if it
becomes inconvenient.

This is the real innovators dilemma: there is no path to guaranteed (or even
likely) victory. You can take a chance on the future but it is likely to kill
you faster than clinging to the past.

~~~
nradov
Sure there are no guarantees. Even leaders who understand the innovator's
dilemma eventually miss a disruptive shift in the market and lose their
dominant position. That's why I'm not too concerned about the current
dominance of large tech companies like Apple, Google, and Facebook. In 50
years MBA students will probably be reading case studies about how they
screwed up and were acquired for pennies on the dollar by competitors who
don't even exist today.

------
jasim
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
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
> 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.

------
pauldix
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
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.

~~~
quietbritishjim
_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-s...](https://www.joelonsoftware.com/2000/08/09/the-joel-
test-12-steps-to-better-code/)

~~~
richard_todd
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
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
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.

~~~
dpark
Ah, I see what you mean. Thanks

------
pjc50
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.

~~~
dfee
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
That was surprising ... perhaps "Penpoint OS" would be better.
[https://en.wikipedia.org/wiki/PenPoint_OS](https://en.wikipedia.org/wiki/PenPoint_OS)

------
jmiserez
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
I am pretty sure that the CRLF ending was inherited from CP/M.

~~~
mmastrac
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!

~~~
leoc
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).

------
shafte
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
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.

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

~~~
bklaasen
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
Para 9, page 4

------
krylon
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
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
Thank _you_! That sounds like a fascinating read, I'll get right on it!

------
frou_dh
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.

~~~
pjc50
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?

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

~~~
ams6110
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.

~~~
nradov
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.

~~~
slededit
The Microsoft culture was one of fighting for your own resources. If you
failed to receive them you were to blame.

Bill Gates formed a highly competitive internal environment. You were expected
to stand up and fight for your cause - even against BillG himself. If you were
right against Bill it was extremely good for your career. This was a time
where the success of a BillG review was determined by how many F-bombs came
out, and it was never zero.

For more information: [https://www.joelonsoftware.com/2006/06/16/my-first-
billg-rev...](https://www.joelonsoftware.com/2006/06/16/my-first-billg-
review/)

Also understand MSFT culture has changed dramatically since that time. Its no
longer representative of the company today.

------
userbinator
MS released the source code for version 1.1a of this application:

[http://www.computerhistory.org/atchm/microsoft-word-for-
wind...](http://www.computerhistory.org/atchm/microsoft-word-for-
windows-1-1a-source-code/)

(You can find copies scattered around GitHub and elsewhere too.)

------
ptaipale
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.

------
orf
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
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.

------
rusanu
Was the post-mortem itself typed in Word?

------
Tempest1981
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"

------
roland35
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.

~~~
robaato
[https://successfulsoftware.net/2017/02/10/how-much-code-
can-...](https://successfulsoftware.net/2017/02/10/how-much-code-can-a-coder-
code/)

------
Tempest1981
"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?

------
cheschire
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
They weren't building a multi-platform product, and in fact he resents that so
much Mac code was foisted on them.

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

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

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

~~~
pjc50
Very different tool for different purposes. And it's never really been
WYSIWYG.

~~~
antoineMoPa
(?) Both can be used for CVs, letters, lab reports, publications. My life was
only simplified when I switched to LaTeX. WYSIWYGs are overrated.

~~~
pjc50
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.

