Richard's mismanagement set the tone for the next three years.
December 31, 2018 2:12 PM Subscribe
This post was deleted for the following reason: Poster's Request -- travelingthyme
There were 13 developers working on Microsoft Word in the 1980s? That's amazing.
posted by ambrosen at 2:27 PM on December 31, 2018
posted by ambrosen at 2:27 PM on December 31, 2018
There are some good general principles about software development and project management in the postmortem, and quite a lot of open loathing of Jeff.
posted by figurant at 2:32 PM on December 31, 2018 [1 favorite]
posted by figurant at 2:32 PM on December 31, 2018 [1 favorite]
This thing reads like a manual of poor organization. It sounds like they had a lot of good people working in an uncoordinated way. Stuff like this shows how far off the rails it all went:
“...This program was an attempt to instill some of the methods of Zero-defects into a project that had gone a long time using an infinte-defects methodology and was too far in its development to consider starting from scratch.”
Super rough.
posted by Leeway at 2:59 PM on December 31, 2018 [1 favorite]
“...This program was an attempt to instill some of the methods of Zero-defects into a project that had gone a long time using an infinte-defects methodology and was too far in its development to consider starting from scratch.”
Super rough.
posted by Leeway at 2:59 PM on December 31, 2018 [1 favorite]
I feel pretty sorry for Peter Jackson, whose LinkedIn (not linked here) strongly suggests that he was massively overpromoted too early, and floundered afterwards.
posted by ambrosen at 3:01 PM on December 31, 2018 [1 favorite]
posted by ambrosen at 3:01 PM on December 31, 2018 [1 favorite]
Ha! One of my oldest and best friends was in attendance. (Crosses fingers and hopes they're not fingered, I doubt it, but you never know.)
posted by maxwelton at 3:04 PM on December 31, 2018
posted by maxwelton at 3:04 PM on December 31, 2018
My own experience as a developer (some levels below the folks on this team in all likelihood) is that a tight specification, combined with program managers dedicated to keeping that spec tight, is one of the best things that can happen to a dev project.
Everyone is into feature creep ("wouldn't it be cool if...!") and feature creep is what kills products. Having someone to say "you're right, that would be cool, let's do it next version" is critical.
And Christ almighty, the truest words in this document are about prototypes. I've worked on far too many projects where the fast moving prototype is ALSO supposed to be the thing which could "go live" next week and not fall over, even as the feature set is being re-written. That's what prototypes are for, go to town. But the idea that your bailing-wire-and-chewing-gum structure is also supposed to be the core code is an idiot's fallacy.
posted by maxwelton at 3:54 PM on December 31, 2018 [8 favorites]
Everyone is into feature creep ("wouldn't it be cool if...!") and feature creep is what kills products. Having someone to say "you're right, that would be cool, let's do it next version" is critical.
And Christ almighty, the truest words in this document are about prototypes. I've worked on far too many projects where the fast moving prototype is ALSO supposed to be the thing which could "go live" next week and not fall over, even as the feature set is being re-written. That's what prototypes are for, go to town. But the idea that your bailing-wire-and-chewing-gum structure is also supposed to be the core code is an idiot's fallacy.
posted by maxwelton at 3:54 PM on December 31, 2018 [8 favorites]
To me, the main problem seems to have been the usual combination of a predefined set of features and deadline pressure.
posted by Ickster at 5:04 PM on December 31, 2018 [1 favorite]
posted by Ickster at 5:04 PM on December 31, 2018 [1 favorite]
Interesting stuff. This bit:
It also reminds me of Stalin and Mao's responses to the plans that were presented to them: The plans were never optimistic enough. This is supposed to be a great leap forward, dammit. Don't give me your engineer's pessimism.
posted by clawsoon at 5:31 PM on December 31, 2018 [5 favorites]
The situation becomes worse since no one wants to see the schedule that would be accurate. Every estimate made by a developer was challenged, first by their manager then by his manager then by Program Management. This caused the initial estimates to always be far sort of what would be realistic....is completely typical of projects in almost all industries.
It also reminds me of Stalin and Mao's responses to the plans that were presented to them: The plans were never optimistic enough. This is supposed to be a great leap forward, dammit. Don't give me your engineer's pessimism.
posted by clawsoon at 5:31 PM on December 31, 2018 [5 favorites]
It's also an illustration of how the sunk cost fallacy can sometimes be useful. If the people with money had known upfront how much it would cost to build the full Microsoft Office suite, they might never have put the money up. They didn't know, though. They thought that the Opus project was going to be the "end-all windows office", and that it would take maybe a couple of years at the most. If they had known the true upfront cost - if they had listened to accurate project estimates - they might not have handed over the money to get started, and Microsoft might not have had its massively profitable Office franchise. Maybe we'd all be using the GEM suite instead.
posted by clawsoon at 5:42 PM on December 31, 2018 [2 favorites]
posted by clawsoon at 5:42 PM on December 31, 2018 [2 favorites]
clawsoon: "If they had known the true upfront cost - if they had listened to accurate project estimates - they might not have handed over the money to get started"
...but it's worth saying that if they were an organization with that kind of maturity, then they would've avoided many of the problems that inflated that "true" cost.
I'd heard about this post-mortem before, originally as an aside in this Joel on Software post. I didn't ever expect to read it. It's fascinating and still full of relevant wisdom.
Those who forget the past are doomed to estimate 2 story points, for a feature that requires design approval from a cross-team initiative, multiple requirements iterations including a customer preview, integration with multiple services (both internal and external), and being assigned to an intern who's the VP's friend's son and "is good at computers."
posted by Riki tiki at 6:37 PM on December 31, 2018 [6 favorites]
...but it's worth saying that if they were an organization with that kind of maturity, then they would've avoided many of the problems that inflated that "true" cost.
I'd heard about this post-mortem before, originally as an aside in this Joel on Software post. I didn't ever expect to read it. It's fascinating and still full of relevant wisdom.
Those who forget the past are doomed to estimate 2 story points, for a feature that requires design approval from a cross-team initiative, multiple requirements iterations including a customer preview, integration with multiple services (both internal and external), and being assigned to an intern who's the VP's friend's son and "is good at computers."
posted by Riki tiki at 6:37 PM on December 31, 2018 [6 favorites]
Aw. Years later I was learning to be a coder by automating the CD_ROM documentation for the 'soft Languages* group. I was therefore doing more work in WordBasic than it had been built to do. On one walk back from lunch, which is when I got a lot of extremely useful advice from the real programmers writing Visual C, etc., I was kvetching that it had taken me days to work out that if you nested control loops in WB more than sixteen levels deep it failed silently and unpredictably.
One of the coders I was complaining is in that cc' list, had been at the postmortem, was uncharacteristically slow to respond and finally said something like "we didn't expect this use case". And I think we switched to a discussion of designing error messages. Retroactive hat tip, I had no idea it had been that bad.
* computer languages and human languages: we were using up any gains from switching away from print by being told to release in German and Japanese not more than a month after the final English version.
posted by clew at 6:42 PM on December 31, 2018 [7 favorites]
One of the coders I was complaining is in that cc' list, had been at the postmortem, was uncharacteristically slow to respond and finally said something like "we didn't expect this use case". And I think we switched to a discussion of designing error messages. Retroactive hat tip, I had no idea it had been that bad.
* computer languages and human languages: we were using up any gains from switching away from print by being told to release in German and Japanese not more than a month after the final English version.
posted by clew at 6:42 PM on December 31, 2018 [7 favorites]
> It's also an illustration of how the sunk cost fallacy can sometimes be useful.
This times a million. I led a software project for 8 years that would have never progressed past year one if it wasn't for sunk cost fallacy. Sunk costs warped our decision making early on, but zero marginal costs rescued the project in the end. In fact I was just listening a podcast between Kahneman and Tyler Cowen and they mentioned that very aspect of tech and sunk costs.
posted by a complicated history at 7:35 AM on January 1, 2019
This times a million. I led a software project for 8 years that would have never progressed past year one if it wasn't for sunk cost fallacy. Sunk costs warped our decision making early on, but zero marginal costs rescued the project in the end. In fact I was just listening a podcast between Kahneman and Tyler Cowen and they mentioned that very aspect of tech and sunk costs.
posted by a complicated history at 7:35 AM on January 1, 2019
Total bugs postponed: 1197
Well, that explains a lot.
posted by meehawl at 9:01 AM on January 1, 2019
Well, that explains a lot.
posted by meehawl at 9:01 AM on January 1, 2019
I dislike lengthy posts that are littered with extraneous links adding "context". Feels like homework I'm supposed to do, or something
There's a middle ground between naming your variable "x" and naming it "this_array_stores_the_full_history_of_variable_assignments_used_in_metafilter_posts_since_1995", to make a relevant analogy.
One sentence of explanatory context for why general readers who haven't heard of Opus, or wouldn't even know that this post is about software development, might be interested in the post also does not need its own extra link (or "homework" for the reader).
posted by eviemath at 9:40 AM on January 1, 2019 [10 favorites]
There's a middle ground between naming your variable "x" and naming it "this_array_stores_the_full_history_of_variable_assignments_used_in_metafilter_posts_since_1995", to make a relevant analogy.
One sentence of explanatory context for why general readers who haven't heard of Opus, or wouldn't even know that this post is about software development, might be interested in the post also does not need its own extra link (or "homework" for the reader).
posted by eviemath at 9:40 AM on January 1, 2019 [10 favorites]
I hope Bryan is OK
posted by thelonius at 11:46 AM on January 1, 2019 [3 favorites]
posted by thelonius at 11:46 AM on January 1, 2019 [3 favorites]
Man, I've lived almost every mistake in this document during my career.
This was back in the days before project management and product management became separate things. Doesn't excuse Richard never writing down the requirements, but in modern software something would get written down -- probably by the program manager translating what the product manager (over-)demanded.
posted by dw at 12:01 PM on January 1, 2019
This was back in the days before project management and product management became separate things. Doesn't excuse Richard never writing down the requirements, but in modern software something would get written down -- probably by the program manager translating what the product manager (over-)demanded.
posted by dw at 12:01 PM on January 1, 2019
It was long enough after The Mythical Man-Month to expect -- in some wishful sense of `expect' -- written requirements. (1975 edition of The Mythical Man-Month at archive.org!)
posted by clew at 12:08 PM on January 1, 2019
posted by clew at 12:08 PM on January 1, 2019
It's amusing to see all the caveats about table formatting — most of which MS accidentally blew up again with their 2015/6 refresh of Word.
posted by scruss at 6:22 PM on January 1, 2019 [1 favorite]
posted by scruss at 6:22 PM on January 1, 2019 [1 favorite]
This kind of stuff is fascinating, even as a non programmer. Thanks.
posted by salvia at 7:02 AM on January 2, 2019
posted by salvia at 7:02 AM on January 2, 2019
Well, first & trivially: I've stayed in the Bellevue Red Lion Inn mentioned in the first sentence, which is funny to me.
Second, though: I was in the industry already when W4W shipped, and this line made me laugh out loud with incredulity:
Word 5 for DOS was a really great product. Sure, it was from the pre-Windows era where every program had its own idiosyncratic interface and required its own print drivers, but it was FAST, STABLE, and VERY capable. (The last DOS version, Word 5.5, was just a reskin, forcing the File/Edit/Etc type menus on it; Word 5 was the last "real" version of the DOS word processor.)
Trying to shift from Word 5 to W4W was a nonstarter for most people. It was just worse in every way. That the memo's author thinks they did something good says a LOT about the MSFT of the era.
But, yeah, the high-level failures here are the standard ones you see in software development. The thing is, though, these were known risks 30 years ago. That Microsoft fell to them even knowing they existed just shows how dangerous and prevalent they can be, especially if management isn't clue-full.
posted by uberchet at 8:46 AM on January 2, 2019 [1 favorite]
Second, though: I was in the industry already when W4W shipped, and this line made me laugh out loud with incredulity:
"The Opus project has been a long one. Many things went wrong and many things went right, but the final product that was produced is one that we can all be proud of."That is some SERIOUS Kool-aid drinking. The initial releases of W4W were completely awful -- slow, buggy, prone to crashes and lockups that forced a reboot, and generally inferior in EVERY POSSIBLE WAY to Word 5 and WordPerfect. Pretty icons and menus are one thing, but they're absolutely something that has to come AFTER actual usability, and Microsoft failed on this front utterly and completely.
Word 5 for DOS was a really great product. Sure, it was from the pre-Windows era where every program had its own idiosyncratic interface and required its own print drivers, but it was FAST, STABLE, and VERY capable. (The last DOS version, Word 5.5, was just a reskin, forcing the File/Edit/Etc type menus on it; Word 5 was the last "real" version of the DOS word processor.)
Trying to shift from Word 5 to W4W was a nonstarter for most people. It was just worse in every way. That the memo's author thinks they did something good says a LOT about the MSFT of the era.
But, yeah, the high-level failures here are the standard ones you see in software development. The thing is, though, these were known risks 30 years ago. That Microsoft fell to them even knowing they existed just shows how dangerous and prevalent they can be, especially if management isn't clue-full.
posted by uberchet at 8:46 AM on January 2, 2019 [1 favorite]
Now I can see why Microsoft Word MVPs gave advice like "don't use sub-documents, and if you do then edit your sub-documents separately and keep lots of backups". IIRC Microsoft Word uses (has?) a really poorly-thought-out internal data structure. It's something like a cross between a tree and a list of changes. So let's say that you want something like this:
Some of the answers are computationally complicated if your underlying data structure isn't designed for them. And if there are any bugs at all in your handling of these complicated structures, they will multiply and crash your system. Microsoft did not get this right, which is why you often ended up with fragmented lists, and why when it came to things like sub-documents Microsoft Word MVPs gave advice like "don't use these, and if you do then keep lots of backups". And now I can see why these things simply didn't work correctly: they never had the time to sit down and think about them.
posted by Joe in Australia at 3:11 PM on January 2, 2019 [1 favorite]
URGENT THINGSThe natural/naive way for users to enter this is to start formatting as a list, then format a bit in the middle as a heading. You can see that this is a complicated thing to do right - is this now one list or two? If it's one list, is the bit in the middle actually a heading (for purposes of indexing and so forth) or part of the list? If the user decides to start formatting a bit in the middle as a list, is it a sublist, or a continuation of the main list, or maybe its own entity? These things are not only conceptually complicated, it's hard to know what should be done. For instance, should two adjacent lists be merged? Users probably want to be able to merge lists, especially if they were originally one list, but what if they now have inconsistent numbers? Or inconsistent numbering systems? Should it just happen automatically or should there be Yet Another Command? If it happens automatically it will probably annoy users who weren't expecting it, but if there's an explicit command then what should happen to any text remaining between the two lists? Or three lists, or whatever crazy mixture of stuff the user throws at it?
1.
2.
3.
LESS URGENT
4.
5.
6.
Some of the answers are computationally complicated if your underlying data structure isn't designed for them. And if there are any bugs at all in your handling of these complicated structures, they will multiply and crash your system. Microsoft did not get this right, which is why you often ended up with fragmented lists, and why when it came to things like sub-documents Microsoft Word MVPs gave advice like "don't use these, and if you do then keep lots of backups". And now I can see why these things simply didn't work correctly: they never had the time to sit down and think about them.
posted by Joe in Australia at 3:11 PM on January 2, 2019 [1 favorite]
« Older 2018: Escalation | Far Out Newer »
This thread has been archived and is closed to new comments
posted by Popular Ethics at 2:22 PM on December 31, 2018 [6 favorites]