Moishe Lettvin
moishelettvin.blogspot.com · Personal blog · on HN since 2007
Moishe Lettvin, a former Microsoft engineer, writes about software craftsmanship and large-company dysfunction, best known for his Windows shutdown post.
What HN saysHN links his Windows shutdown post as an explanation of how bureaucracy in large organizations produces odd results like Vista's shutdown menu.
33HN people shared it
24linked it in comments
13stories submitted
383story points
11 months agolast shared
2007people per year2026
Most-shared posts
- 1The Windows Shutdown crapfest (2006)27 people · 341 points · first shared 2008 · 112 comments on HN
- 2The Windows Shutdown crapfest (2006)2 people · 3 points · first shared 2014 · discussion on HN
- 3Less programming, more skill?1 people · 22 points · first shared 2007 · 10 comments on HN
- 4Large companies and 'A' talent1 people · 13 points · first shared 2007 · discussion on HN
- 5Software and craftsmanship1 people · 4 points · first shared 2007 · 1 comments on HN
- 6Windows shutdown crapfest1 people · first shared 2010
- 7Windows shutdown crapfest1 people · first shared 2016
- 8Windows shutdown crapfest1 people · first shared 2018
What HN people wrote when they linked it
jasode · 2023-07-16
Some more links of how bureaucracy inevitably creeps in as organizations get larger:
- http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
- http://www.lizengland.com/blog/2014/04/the-door-problem/
Another famous anecdote was Google CEO Larry Page firing all of his project managers during its early startup days because he felt they just got in the way of his programmers getting things done. But his executive team convinced him to reverse his decision. Think about that, even the powerful owner of Google couldn't get rid of the layers of bureaucracy. He eventually relented.
No non-trivial project has come up with a way to coordinate a large # of programmers where the participants themselves don't complain about the bureaucracy. In other words, learn to love Jira -- because it's inevitable?!?
latch · 2011-02-28
An assumption? We've been told pretty directly how complicated the process is (often with pride).
See the 14 steps which turn a 5 minute code change into a multi-man-month-mammoth:
http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298.aspx
Or the now infamous Windows Shutdown "crapfest":
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
There's more. And I have no problem with the author stating how great coding is (because he has an office and a nice computer!). However, while your right hand is telling us how great it is and we shouldn't assume otherwise, your left hand is telling us how horrible it is.
Yaggo · 2010-09-20
Actually, according to the following sources, the content is written to disk _before_ entering sleep. This can be done very quickly because most of the data is already in swap file.
http://support.apple.com/kb/HT1757?viewlocale=en_US
http://www.macworld.com/article/53460/2006/10/safesleep.html
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
danudey · 2025-12-01
An explanation of why the Windows Vista shutdown bit is in a weird new menu: https://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.h…
sys_64738 · 2021-07-23
Some insight around this time.
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
mumblemumble · 2019-10-15
This oldie seems relevant: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
1 year to build Windows Vista's new shutdown menu, with a total of 43 people somehow involved in its design. If this is how Windows developers still have to work, it's no wonder.
That said, I would readily believe that the roots of this story have more to do with the complexity of modern OSes than any particulars of Microsoft culture. In terms of software quality, OS X peaked about 15 years ago, and has been steadily getting flakier ever since. And the Linux community has been struggling for virtually its entire existence, without success, to deliver a well-polished desktop experience.
gurkendoktor · 2018-06-02
The design history of Skype for iPhone was particularly misguided: First it was a native UIKit app, then MS put a lot of effort into making it look and behave exactly like a Windows Phone app [1], down to the unusual gestures. When they gave up on that, the app reverted to a native UIKit design, but just a few updates later we got the current Snapchat clone instead. Needless to say, features regularly got lost during these radical redesigns.
That‘s still very clearly the same Microsoft where a gazillion layers of dumb middle management ruin everything[2].
[1] http://www.iphonehacks.com/2014/06/skype-redesign-iphone-app.html
[2] http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
lozenge · 2018-01-13
> I worked at Microsoft for about 7 years total, from 1994 to 1998, and from 2002 to 2006.
>-The most frustrating year of those seven was the year I spent working on Windows Vista, which was called Longhorn at the time. I spent a full year working on a feature which should've been designed, implemented and tested in a week.
http://moishelettvin.blogspot.co.uk/2006/11/windows-shutdown-crapfest.…
It was brave to reset after Longhorn but it seems not all the bad ways of working could be shaken off.
wvenable · 2016-11-02
Seems like a bit of a contrast between that and this:
http://moishelettvin.blogspot.ca/2006/11/windows-shutdown-crapfest.htm…
gnaffle · 2014-02-05
Here's a good story about the shutdown menu in Vista, and how it came to be:
Original rant by Joel Spolsky: http://www.joelonsoftware.com/items/2006/11/21.html
Answer from the guy working on the shutdown menu: http://moishelettvin.blogspot.no/2006/11/windows-shutdown-crapfest.htm…
Another response from the guy that implemented the OSX shutdown menu: http://arno.org/arnotify/2006/11/the-design-of-the-mac-os-x-shutdown-f…
adambyrtek · 2012-01-16
Well, then problems with such process are pretty well documented[1]. For comparison, at Google global refactorings are pretty common and usually painless, there are even custom tools to support such changes (push them through code review, ensure no tests are broken etc.)
[1] http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
bad_user · 2011-03-23
If you're talking about "one product" which you want to sell, then build Windows or Microsoft Office with 5 programmers.
the communication and coordination isn't between
all 1,000 developers.
No, it's worse. Teams usually don't know what the others are doing, leading to broken, blocked or half-baked features and work duplication.
Here's an example: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
Having all those 1000 developers talk to one another would solve all problems, but this is a problem of scale which processes solve to a certain extent. Your opinion also highlights what's wrong with software development as a whole -- you seem to be under the impression that you can go and hack stuff in a vacuum, without interacting with others.
cpr · 2010-10-29
MS is a pretty ponderous beast. Remember Joel's pointer to the story about someone trying to fix the shutdown experience?
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
Sounds like it takes years to get the legs moving together, which means it's too late for IE9 on the phone for a while...
dtf · 2009-10-19
Someone linked to this post in the comments, which I'd never seen before. It's by the guy who wrote the Vista shutdown menu, and it's pretty depressing reading:
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
dhouston · 2009-05-03
Probably what happens when no one's in charge and the legal, backwards compatibility, etc. teams have veto power over the UX people.
See also: (re: windows vista shutdown UI)
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
Maciek416 · 2009-04-21
The contrast here is being made between two development styles: A centralized, controlled, and focused production system at Apple, versus what Microsoft apparently had before Windows 7: A network of fiefdoms which fought each other over implementation and design details but nevertheless had to secure each others' approval for changes. This brought about stalemates and some truly bizarre outcomes. Here's the famous story about the Windows shutdown menu relating to this:
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
If Microsoft has overcome these [alleged] problems, it would represent a significant change in their development style.
ricardo · 2008-06-25
When Microsoft started out it operated under a pretty flat organizational structure, similar to how Google is run. They've gotten fat in the middle (management) over the years and it's stifled any chance they've had of getting anything done.
See this blog post from a former MS employee about the year it took to design the shutdown menu in Vista: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
wanorris · 2008-04-24
> there is a dedicated team of around 50 people just devoted to managing the "Start" button.
Worse: it took 43 people just to build the shutdown feature.
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
This article will tell you everything you ever needed to know about why Vista turned out the way it did.
webmaven · 2020-12-17
> When you use Win32 you get the latest fixes and features even in applications that haven't been updated for two decades - for example you get new common dialogs and access to shell extensions (e.g. TortoiseSvn/Git integration) that didn't exist back when those applications were made.
What you're describing is not backward compatibility, it's forward compatibility.
The OS is backward compatible with old applications that continue to run. The old applications are forward compatible with newer versions of the operating system including some of the new features that are added.
Achieving backward and forward compatibility (the combination is often called "full compatibility") is actually quite difficult. The resources Microsoft throws at this problem and the related coordination costs are massive (and conversely, the progress any individual developer sees on their particular tasks is often glacial)[0]. In the open source world, I think only web browsers typically see anything resembling a similar level of effort applied to evolving the platform while maintaining compatibility with extant (and often buggy) code, and that's still a much smaller problem (though it might not be after another decade or two), since for all intents and purposes, the web as a whole is a "rolling release" system with bugs and incompatibilities popping up and being fixed constantly.
[0] http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
gmiller123456 · 2017-09-06
>they are unable to conceive of a company as anything other
>than a single, gestalt entity, with a single opinion and
>purpose, whose actions are driven by the most basic
>emotions and can be classified as good or evil with
>absolutely no grey-area.
Seems like quite a straw man argument, there probably isn't a single person that actually fits your description. And it certainly does not describe a typical developer.
As infamously documented in "The Windows Shutdown Crapfest" [1], in order for anything to be publicly observed outside of most large bureaucracies, a large number of people are involved, and their only common interest comes from very high up in the bureaucracy. So you usually do end up with a single, simple ideology presented to the public, even though there are a lot of people internally fighting for different things.
[1] http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
mapgrep · 2014-04-22
But some of it was just math -- a large company with many teams that need to coordinate slows things down. I like this anecdote from a Microsoft engineer about how it took a year to design a really crappy shutdown menu with nine (nine!) options.
It turns out there 43 different people who had a voice in the feature, which was hashed out over a series of grinding meetings involving teams responsible for kernel, shell, Tablet PC, Longhorn, and (drumroll please) "Windows Mobile PC User Experience"."
"In Windows, the [repository] node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes."
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
twinge · 2012-02-04
Three big problems with a split up codebase:
1) Instead of doing one large release every week (which facebook does: http://www.facebook.com/video/video.php?v=10100259101684977) you now have dozens or hundreds of smaller releases, a lot more heterogeneity to test for.
2) If you have inter-dependencies on modules you have to grapple with the "diamond dependency" problem. Say module A depends on module B and C, and suppose that module B also depends on C. However, module B depends on C v2.0 but A depends on C v1.0. If they're all split across repositories it's not possible to update a core API in an atomic commit.
3) Now you rely on changes being merged "up" to the root and then you have to merge it "down" to your project. This is one of the reasons Vista was such a slow motion train wreck: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht… -- kernel changes had to
be merged up to the root, then down to the UI, requiring months of very slow iterations to get it right.
DougBTX · 2008-07-28
You may not have read this article before: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.ht…
Here's a relevant quote from the article:
In Windows, this [centralised] model breaks down simply
because there are far too many developers to access one
central repository. So Windows has a tree of
repositories: developers check in to the nodes, and
periodically the changes in the nodes are integrated up
one level in the hierarchy. At a different periodicity,
changes are integrated down the tree from the root to the
nodes. In Windows, the node I was working on was 4 levels
removed from the root. The periodicity of integration
decayed exponentially and unpredictably as you approached
the root so it ended up that it took between 1 and 3
months for my code to get to the root node, and some
multiple of that for it to reach the other nodes. It should
be noted too that the only common ancestor that my team,
the shell team, and the kernel team shared was the root.
With a distributed system, it would be possible to send changes directly between the two groups. You might have a problem keeping the whole Windows source code repository stored locally on your development machine though.