Things not to do when writing software

I figured I’d start off with an old war story. A REALLY old story. From back in the Windows 1.0 days. Once that could never ever happen these days. 

It’s about 2 months before Windows 1.0 is about to ship (so it’s sometime around August/September 1985). Microsoft had announced Windows 18 months before this point, and we were getting HAMMERED in the press about vapor ware. So the team was under a HUGE amount of pressure to ship windows as fast as humanly possible with the maximum feature set. 

Anyway, as I said, it’s about 2 months before ship time. And the developer responsible for the windows memory manager comes in on Monday morning and announces to the team that he’s just checked in a new version of the memory manager that supports swapping movable data segments to disk (up until that point Windows had the ability to discard code segments and reload them but no ability to reload data).

Steve Ballmer, who was the development lead for the project at that point’s only comment was, “Ok, I want to fire the SOB.  I REALLY want to fire the SOB, but we need this feature”.

Things not to do when writing software, part 2 (I thought about putting this in a separate post but I figured I’d include this one in it since it shows the other side of the coin).

Also a Windows 1.0 story. This one’s about the printing subsystem. The developer for the printing system, apparently inspired by the example above, decided to rewrite the printing subsystem in Windows 2 weeks before they were scheduled to ship.

Now most of the time, the way that the developers tested printing in Windows was to load up a file in Notepad, print it on the Epson MX-80 dot matrix printer in their office, and if it worked, they checked in the change. Now Windows 1.0 supported a lot of font features that Notpad didn’t. Things like variable width fonts. And boldfaced and italic text. And underlining. None of which were usually tested.

Well, given the previous track record with printing, Linne’ Puller, the test lead for windows printing absolutely freaked out when she heard that he had made the change, and begged for the opportunity to run a test pass before he checked it in. The developer involved agreed, but he didn’t see what the point was, since he had already thoroughly tested his change.

Linne and Valorie Holden (the other Windows printing tester) worked through the night running tests and come the next morning, they deposited a stack of papers over a foot high onto the developer’s desk.

“So those are the results of the test run? Man, that’s a lot of paper; could you whittle it down to just the failures?”

“No, those ARE just the failures”.

“Oh”.

Needless to say, the feature didn’t get checked in. Once again, testers saved developments hind quarters.

And now for the full disclaimers before I get flamed and quoted on /. as proof positive that Microsoft can’t code it’s way out of a paper bag: This is an old war story It’s almost 20 years old at this point. The Windows team back in those days was known as a bunch of cowboys (that’s actually why Steve Ballmer ended up being in charge of the team). 

Microsoft has gotten a whole lot better at software engineering in the past twenty years. Even at that point it was really clear that both of these examples were clearly things that people shouldn’t do instead of examples of the way that changes should happen.

These days, long before a project gets to the state that Windows was in, the project gets locked down TIGHT. All new features are reviewed by a DCR (Design Change Request) review board, which consists of development, program management, AND test. And all three need to sign off before coding even STARTS on the new feature.

In addition, the test team is intimately involved in the development of new features. At a minimum, before any significant change gets checked in, the process that Linne and Valorie went through has been formalized into what we now call “smoke tests”. Each group at Microsoft has their own version of them (some call them buddy build, some call them private tests), but they all have some form of process that allows the test team to veto/comment on the quality of a change. At some point I’ll write about what a “normal” day looks like from the inside...

Obligatory personal note: Valorie Holden was a summer intern whose internship stretched into December – she was my college girlfriend who had come out to work at Microsoft as a tester for the summer. We got engaged in December of 1985. And we’ve been happily married for the past 17 years.