6 ms·

The Windows Shutdown crapfest

77 points by adambyrtek 16y ago

dchest 16y ago
(2006)
- deleted 16y ago
  [deleted]
- adambyrtek 16y ago
  Sorry, I forgot to mention the date in the title :(
DiabloD3 16y ago
Ahh, this is why I love Linux and XFCE.... XFCE didn't take a year to write such a dialog box.
emehrkay 16y ago
The repository structure seems a bit bad in that it takes months for changes to propagate, but how else should a project as big as windows be handled at the source-level?
- eitally 16y ago
  Well, creating a common vision would have been a good start, as would having had a single owner. There is a point where it becomes more valuable for managers to delegate and step away than it is for them to try and keep abreast of the minutiae. In order for delegation to work there must be comprehensive trust. In my experience, large organizations usually fail miserably at this combination of trust, vision, and delegation [at some point of scaling]. The better you are the better you can scale, but even revered learning organizations like 3M, Bell Labs, and Xerox PARC relied [mostly] on small, self-organizing organic project teams with very little management oversight... but oodles of charisma & responsibility.
- btilly 16y ago
  For an alternative watch http://www.youtube.com/watch?v=sMql3Di4Kgc http://www.youtube.com/watch?v=sMql3Di4Kgc to see how Google does it. Basically most of the company develops on one branch, but no changelist can be checked in without going through peer review. (The talk is about the tool that Google uses for peer review.) It seems to work quite well. Now you can ask how the project size compares. Well http://en.wikipedia.org/wiki/Source_lines_of_code#Example http://en.wikipedia.org/wiki/Source_lines_of_code#Example claims that Windows Server 2003 had 50 million lines of code. http://code.google.com/opensource/ http://code.google.com/opensource/ claims that Google has released over 15 million lines of code across various projects. I guarantee that Google has not released most of its code. Based on those data points I wouldn't be surprised if the sizes were comparable, at least to within an order of magnitude. (However Google's source code is probably significantly better. Google has not been around as long, and does not have the same kinds of accumulated legacy issues that Microsoft does.) Random disclaimer, I work for Google and I like how Google does it.
  - emehrkay 16y ago
    Thanks, I'll check that video out.
  - macrael 16y ago
    Is it really fair to compare the amount of code in windows server to the total amount of code that google maintains? Google has many different software projects, what is the biggest? Search? Android? Gmail? Compare one project to a server operating system and my guess is that the OS is going to be an order of magnitude larger. An OS is an enormously complicated piece of software with lots of co-dependent parts. That's what led the to this pretty horribly complicated source management system.
    - wtallis 16y ago
      Google's stuff may be a lot more modular than Windows, but that's not to say that there aren't inter-dependencies. Google's web services all share just a few back-end technologies (MapReduce, GFS, BigTable) that are comparable to an OS kernel, with things like GMail and Docs hanging off like subsystems. But even things like Gmail, Docs, Calender, Search, etc. aren't even close to independent. The GMail people need to collaborate with the Docs people to handle attachments and the Calendar people to handle to-do lists and event invitations and the GTalk and Voice people to implement the voice and video chat and phone calling. The Picasa people need to collaborate with the the Google Earth and Maps people to handle geotagging, and the GWT (probably) people to deal with the web interface. The Android people need to collaborate with everybody who works on the front-ends of all the other products in order to develop mobile versions or integrate them more deeply in to the OS. Even if the "collaboration" in many of these instances is mostly limited to using an API published by the other group, there's still the need to make sure that those APIs are sufficient to accomplish the task at hand, and obviously Google's UI consistency between products is more than an accident. I think that to the extent that Microsoft's code is more tightly coupled than Google's or that of a desktop Linux distribution, it's mostly their own fault.
- adambyrtek 16y ago
  Thinking about that, looks like this is a perfect example to prove why continuous integration is such a great idea.
- city41 16y ago
  VS2010 was the largest source repository I've ever worked on. It is structured very similar to Windows, all large projects at MS are as far as I know. It ended up being my job was almost entirely dedicated to just maintaining our branches: pushing our updates up to Main, and pulling in fresh changes about once a week. DevDiv has a term for this: BFD, "Branch Facilitator Developer", which for most teams is a full time job of nothing but merging code. For me it was about 70% of my job. Each branch took about 120 gigs of space on disk, and I regularly worked with about 5 branches. Merging our changes into main was a huge ordeal. We had to merge, do a full stack build (which took about 24 hours), and run every single team's tests, which took another 24 to 48 hours. From there it was a bookkeeping task of checking in on all the tests that failed and resolving them, doing performance testing, etc etc. All in all merging to main took roughly a week to pull off. The reverse was always interesting: pulling in new bits from Main to our branch was like playing Russian roulette, what was going to break this time? To add a little spice to all of this, it all took place on alpha builds of Team Foundation Server that was being developed at the same time as everything else. Fun times :)
rbanffy 16y ago
Again?
- adambyrtek 16y ago
  Interesting. I couldn't google the previous entry, Hacker News didn't detect that this as a duplicate as well. http://www.google.com/search?&q=site%3Anews.ycombinator.com+%22shutdown+crapfest%22 http://www.google.com/search?&q=site%3Anews.ycombinator....
  - _delirium 16y ago
    This does look like the first submission, unless SearchYC is missing it: http://searchyc.com/submissions/moishelettvin.blogspot.com http://searchyc.com/submissions/moishelettvin.blogspot.com
    - code_duck 16y ago
      I think it's Reddit and Slashdot where I saw the the first three times.
wccrawford 16y ago
Any time I hear someone say they spent a year working on a few hundred lines of code, I have to wonder how much of the problem was other people, and how much was that person. I suspect there's a ton of exaggeration going on here, and that's probably not the only code they worked on. It's also probably not the highest priority, either.
- dasil003 16y ago
  Any time? Even when the logistics of the situation are explained this clearly, and the coder is responsible for 2% of the decision making process? I really don't see where in this article there's room to chalk the dysfunction up to exaggeration or incompetence.
- dugmartin 16y ago
  I worked on an equivalently small feature on Longhorn/Vista and it took over 18 months for it to be completed. It also depended on shell code and it would take weeks for code to migrate up their tree and back down to us. The fun thing is that two dll's that I built for the feature ended up being standalone dlls in Windows\System32. I thought someone would merge that code into some common dll but I guess that wasn't on the schedule.
- lumisura 16y ago
  I'm not even going to tell you how long it took and how complex it was to replace one single icon sometimes in Vista. I worked in the Windows UX team at the time and tried really hard during Windows 7 to improve that process, because there were so many people involved and so many hours spent for such simple things. So yes, I believe what this guys is saying about his feature is possible - to swap an icon we sometimes had to track a ridiculous number of people, wait several builds to see it, and get approval from a room full of people many times several management levels above me.
  - 2arrs2ells 16y ago
    I fought similar battles (but at a much smaller scale) trying to change some of inane dialog box text/tooltips in InfoPath for a feature I owned as a PM. I was an intern, but the pushback was rarely along the lines of "Your version isn't better" but rather "We can't handle the globalization/internationalization/testing/etc burden of making the change."
some1else 16y ago
I just used this in a metaphor today, to explain why Windows is inferior to Mac OS and Linux Gnome
philwelch 16y ago
I love this article. It's practically a case study for Fred Brooks' "mythical man-month".

77 points by adambyrtek 16y ago

dchest 16y ago

(2006)

deleted 16y ago
[deleted]
adambyrtek 16y ago
Sorry, I forgot to mention the date in the title :(

DiabloD3 16y ago

Ahh, this is why I love Linux and XFCE.... XFCE didn't take a year to write such a dialog box.

emehrkay 16y ago

The repository structure seems a bit bad in that it takes months for changes to propagate, but how else should a project as big as windows be handled at the source-level?

eitally 16y ago
Well, creating a common vision would have been a good start, as would having had a single owner. There is a point where it becomes more valuable for managers to delegate and step away than it is for them to try and keep abreast of the minutiae. In order for delegation to work there must be comprehensive trust. In my experience, large organizations usually fail miserably at this combination of trust, vision, and delegation [at some point of scaling]. The better you are the better you can scale, but even revered learning organizations like 3M, Bell Labs, and Xerox PARC relied [mostly] on small, self-organizing organic project teams with very little management oversight... but oodles of charisma & responsibility.
btilly 16y ago
For an alternative watch http://www.youtube.com/watch?v=sMql3Di4Kgc http://www.youtube.com/watch?v=sMql3Di4Kgc to see how Google does it. Basically most of the company develops on one branch, but no changelist can be checked in without going through peer review. (The talk is about the tool that Google uses for peer review.) It seems to work quite well. Now you can ask how the project size compares. Well http://en.wikipedia.org/wiki/Source_lines_of_code#Example http://en.wikipedia.org/wiki/Source_lines_of_code#Example claims that Windows Server 2003 had 50 million lines of code. http://code.google.com/opensource/ http://code.google.com/opensource/ claims that Google has released over 15 million lines of code across various projects. I guarantee that Google has not released most of its code. Based on those data points I wouldn't be surprised if the sizes were comparable, at least to within an order of magnitude. (However Google's source code is probably significantly better. Google has not been around as long, and does not have the same kinds of accumulated legacy issues that Microsoft does.) Random disclaimer, I work for Google and I like how Google does it.
- emehrkay 16y ago
  Thanks, I'll check that video out.
- macrael 16y ago
  Is it really fair to compare the amount of code in windows server to the total amount of code that google maintains? Google has many different software projects, what is the biggest? Search? Android? Gmail? Compare one project to a server operating system and my guess is that the OS is going to be an order of magnitude larger. An OS is an enormously complicated piece of software with lots of co-dependent parts. That's what led the to this pretty horribly complicated source management system.
  - wtallis 16y ago
    Google's stuff may be a lot more modular than Windows, but that's not to say that there aren't inter-dependencies. Google's web services all share just a few back-end technologies (MapReduce, GFS, BigTable) that are comparable to an OS kernel, with things like GMail and Docs hanging off like subsystems. But even things like Gmail, Docs, Calender, Search, etc. aren't even close to independent. The GMail people need to collaborate with the Docs people to handle attachments and the Calendar people to handle to-do lists and event invitations and the GTalk and Voice people to implement the voice and video chat and phone calling. The Picasa people need to collaborate with the the Google Earth and Maps people to handle geotagging, and the GWT (probably) people to deal with the web interface. The Android people need to collaborate with everybody who works on the front-ends of all the other products in order to develop mobile versions or integrate them more deeply in to the OS. Even if the "collaboration" in many of these instances is mostly limited to using an API published by the other group, there's still the need to make sure that those APIs are sufficient to accomplish the task at hand, and obviously Google's UI consistency between products is more than an accident. I think that to the extent that Microsoft's code is more tightly coupled than Google's or that of a desktop Linux distribution, it's mostly their own fault.
adambyrtek 16y ago
Thinking about that, looks like this is a perfect example to prove why continuous integration is such a great idea.
city41 16y ago
VS2010 was the largest source repository I've ever worked on. It is structured very similar to Windows, all large projects at MS are as far as I know. It ended up being my job was almost entirely dedicated to just maintaining our branches: pushing our updates up to Main, and pulling in fresh changes about once a week. DevDiv has a term for this: BFD, "Branch Facilitator Developer", which for most teams is a full time job of nothing but merging code. For me it was about 70% of my job. Each branch took about 120 gigs of space on disk, and I regularly worked with about 5 branches. Merging our changes into main was a huge ordeal. We had to merge, do a full stack build (which took about 24 hours), and run every single team's tests, which took another 24 to 48 hours. From there it was a bookkeeping task of checking in on all the tests that failed and resolving them, doing performance testing, etc etc. All in all merging to main took roughly a week to pull off. The reverse was always interesting: pulling in new bits from Main to our branch was like playing Russian roulette, what was going to break this time? To add a little spice to all of this, it all took place on alpha builds of Team Foundation Server that was being developed at the same time as everything else. Fun times :)

rbanffy 16y ago

Again?

adambyrtek 16y ago
Interesting. I couldn't google the previous entry, Hacker News didn't detect that this as a duplicate as well. http://www.google.com/search?&q=site%3Anews.ycombinator.com+%22shutdown+crapfest%22 http://www.google.com/search?&q=site%3Anews.ycombinator....
- _delirium 16y ago
  This does look like the first submission, unless SearchYC is missing it: http://searchyc.com/submissions/moishelettvin.blogspot.com http://searchyc.com/submissions/moishelettvin.blogspot.com
  - code_duck 16y ago
    I think it's Reddit and Slashdot where I saw the the first three times.

wccrawford 16y ago

Any time I hear someone say they spent a year working on a few hundred lines of code, I have to wonder how much of the problem was other people, and how much was that person. I suspect there's a ton of exaggeration going on here, and that's probably not the only code they worked on. It's also probably not the highest priority, either.

dasil003 16y ago
Any time? Even when the logistics of the situation are explained this clearly, and the coder is responsible for 2% of the decision making process? I really don't see where in this article there's room to chalk the dysfunction up to exaggeration or incompetence.
dugmartin 16y ago
I worked on an equivalently small feature on Longhorn/Vista and it took over 18 months for it to be completed. It also depended on shell code and it would take weeks for code to migrate up their tree and back down to us. The fun thing is that two dll's that I built for the feature ended up being standalone dlls in Windows\System32. I thought someone would merge that code into some common dll but I guess that wasn't on the schedule.
lumisura 16y ago
I'm not even going to tell you how long it took and how complex it was to replace one single icon sometimes in Vista. I worked in the Windows UX team at the time and tried really hard during Windows 7 to improve that process, because there were so many people involved and so many hours spent for such simple things. So yes, I believe what this guys is saying about his feature is possible - to swap an icon we sometimes had to track a ridiculous number of people, wait several builds to see it, and get approval from a room full of people many times several management levels above me.
- 2arrs2ells 16y ago
  I fought similar battles (but at a much smaller scale) trying to change some of inane dialog box text/tooltips in InfoPath for a feature I owned as a PM. I was an intern, but the pushback was rarely along the lines of "Your version isn't better" but rather "We can't handle the globalization/internationalization/testing/etc burden of making the change."

some1else 16y ago

I just used this in a metaphor today, to explain why Windows is inferior to Mac OS and Linux Gnome

philwelch 16y ago

I love this article. It's practically a case study for Fred Brooks' "mythical man-month".