Slashdot Log In
Why Vista Took So Long
Posted by
kdawson
on Mon Nov 27, 2006 12:31 PM
from the changing-lightbulbs dept.
from the changing-lightbulbs dept.
twofish writes, "Following on from Joel Spolsky's blog on the Windows Vista shutdown menu, Moishe Lettvin, a former member of the Windows Vista team (now at Google) who spent a year working on the menu, gives an insight into the process, and some indication as to what the approximately 24 people who worked on the shutdown menu actually did. Joel has responded in typically forthright fashion." From the last posting: "Every piece of evidence I've heard from developers inside Microsoft supports my theory that the company has become completely tangled up in bureaucracy, layers of management, meetings ad infinitum, and overstaffing. The only way Microsoft has managed to hire so many people has been by lowering their hiring standards significantly. In the early nineties Microsoft looked at IBM, especially the bloated OS/2 team, as a case study of what not to do; somehow in the fifteen year period from 1991–2006 they became the bloated monster that takes five years to ship an incoherent upgrade to their flagship product."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Linux development model? (Score:5, Funny)
Re:Linux development model? (Score:5, Insightful)
To call it "the Linux development model" is somewhat arrogant I think. It appears more that Microsoft is trying to take their time and putting in extra effort to make this release literally the best Windows release to date, because the last thing they want is another Windows ME. This process applies to any software group, be it OSS, Apple, IBM, and yes, Microsoft.
To borrow a quote from Shigeru Miyamoto, "A delayed game is eventually good, a bad game is bad forever." I think that applies to pretty much any software project, though of course "good" is relative to the user.
Parent
Re:Linux development model? (Score:5, Funny)
Parent
Re:Linux development model? (Score:5, Funny)
Parent
Re:Linux development model? (Score:5, Insightful)
Parent
Re:Linux development model? (Score:5, Interesting)
But...
There is never an ROI on doing code cleanup and making it easier to maintain from a manager / new development programmer's perspective.
As a maintenance programmer tho... I see faster, more stable, easier to maintain code out of even the little things I manage to sneak in. A solid code cleaning can cut weeks or months off of other projects on the same code base. From everything we've heard- windows source is a mess.
What they probably need to do is spend 6 months and do an architectural code cleanup. There would be no immediately ROI however every project for the rest of time would benefit so theoretically their ROI is infinite.
As a maintenance programmer, I've frequently taken multiple pages of code out of programs without changing their functionality. In a large number of cases products are shipped by the development staff with dead code, goofy code, very inefficient code, redundant code, etc.
Parent
Welcome to inevitability (Score:4, Insightful)
Re:Welcome to inevitability (Score:5, Interesting)
Parent
Re:Welcome to inevitability (Score:5, Funny)
No, that's because they used 5-bit ids in their database.
Parent
Re:Welcome to inevitability (Score:5, Funny)
Parent
Re:Welcome to inevitability (Score:5, Interesting)
Parent
wrong Steve (Score:5, Funny)
They're stuck with the other one
Parent
Re:Welcome to inevitability (Score:5, Interesting)
Parent
Re:Welcome to inevitability (Score:5, Interesting)
It's changed business models a few times. It started out as a playing card company. If you want to discuss a successful long-lived organization - look at the Catholic church. It's been around for two thousand years. It's got just a few layers of management and at the top 183 cardinals report to the Pope.
Parent
Re:Welcome to inevitability (Score:5, Funny)
Pretty impressive when you consider that for all that time their ONLY product has been vapourware.
Parent
Re:Welcome to inevitability (Score:5, Informative)
Parent
Re:Welcome to inevitability (Score:5, Interesting)
Conversely, when you are far enough past your competition, you have to decide where you want to go. Microsoft's business vision looks backwards (defensive) and sidewards (leveraging its unique position in desktop os and office software to gain entry into new markets and new revenue streams). They don't seem to be looking where they are going, because they're already where they want to be.
Parent
Re:Welcome to inevitability (Score:4, Interesting)
Parent
Re:Welcome to inevitability (Score:5, Funny)
Not really. They're near-impossible to housetrain!
(A libertarian shat on my carpet once. Claimed the free market would sort it out. No it sodding didn't.)
Parent
Re:Welcome to inevitability (Score:5, Funny)
* France: never was communist
* It seems you recognize only 5 democracies in the world, one of which is Chile
* You seem to think it was possible to do cool things in Nazi Germany or fascist Italy
* You lump Nazi Germany and fascist Italy together with Holland or Sweden, totally ignoring the huge differences in favor of superficial similarities
* You ignore that that Holland and Sweden are democracies
* If you believe France is communist, why not Sweden?
* You ignore that Nazi Germany had a huge bureaucracy
* You ignore that many democracies in Europe actually have cut bureaucracies over the last 3 decades. Not enough for some tastes, but nevertheless.
I am tired of this.
Parent
Wait for it, wait for it (Score:5, Funny)
Why RTFA? (Score:5, Insightful)
Re:Why RTFA? (Score:5, Informative)
Parent
What if the "Bye" button... (Score:5, Funny)
Why not? (Score:5, Insightful)
So why hurry? For money? In my experience hurrying to make money never works out.
TLF
Huh? (Score:4, Insightful)
Re:Huh? (Score:5, Insightful)
1. I like having my computers available instantly when I want to use them.
2. Turning a machine on and off many times can be harmful, so it is said. Others say it's a myth. I don't know who to believe, but it seems feasible that this could be so.
3. I run back-ups and virus checks during the night.
4. The computers work on protein-folding during their idle time.
5. My machines are in my bedroom, and they keep me nice and warm at night. Besides, there's nothing like the low purr of case fans so send you off to sleep
Parent
Re:Huh? (Score:5, Interesting)
Well with a Desktop you can suspend to disk and then come back rather quickly, with a power off in between. This way you get the power savings, but you also get the fast "boot" time.
But let's look at me. I had a Dell laptop at school. I'd use it at home. Turn it off. Take it to school. Turn it on for class. Use it. Turn it off. Take it to next class/home and repeat. Suspend was very iffy (and didn't help much in the battery life department).
Then I got a Powerbook G4 (which I still use today). Run it at home. Close the lid. Take it to school. Open the lid. IT WAS READY. Within 3 seconds I could start working. When I'm done? No "Start->This->that" to be sure it worked. Just close the lid. I know some PCs worked that way, mine never did (reliably) that I remember. Next class/home? Open the lid. If it got low on power, I'd plug it in. My little laptop has had up to 3 months of uptime (mostly due to major security updates that require restarts). I NEVER need to turn it off. The last time I did was when I was going on an airplane (didn't know if they'd like it suspended during takeoff/landing). It boots relatively fast, but nothing compared to waking up and going to sleep.
If you're a desktop user, I understand your comment. But as a laptop user who has had the pleasure of a Mac, a fast reliable suspend is a HUGE time saver.
Now I'll note that some other people at my school had newer laptops that could suspend/resume just fine. But they took much longer. Some of them approached boot time length, some could do it in 20-30 seconds. No PC there matched my Mac (note: I never asked the few Linux users if they had it working on their laptops). I could suspend/resume my Mac 3 times with ease in the time it took the fastest XP users (and I'll ignore the "Click here to sign on" screen most of them didn't disable).
Parent
Re:Huh? (Score:5, Insightful)
If I'm working on code, I've several editor windows, compiler and terminals open. And usually, if I have to shut down my computer, that would imply I would need to close all those windows and all those applications. Why should I do that when I could just have my computer hibernate or sleep?
I mean, if I am on Linux, I have four active desktops with several browser windows, code and other things.
Shutting down my system implies closing down everything and starting afresh. Why should I, when I can put my system to sleep and restart it with my windows and state preserved?
Parent
Re:Huh? (Score:5, Funny)
That's one of the previous Unix admins I worked with.
He was so clueless about his boxes that every week he'd say "I just wish I had windows servers instead."
Parent
The modern DVCSs would all do better (Score:4, Interesting)
"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."
Monotone, BitKeeper, git, bzr, and so on would all handle this situation efficiently and gracefully; all the repositories can sync to each other and none need be more than a few minutes out of date. Amazing that Microsoft's solution is so poor by comparison
Re:The modern DVCSs would all do better (Score:5, Insightful)
When you get beyond a certain stage of complexity, you need to change the mode of operation. You can't just have everyone submitting random changes.
You have a subgroup of people that work with each other. When something is stable, it gets submitted to the integration branch. Periodically the integration branch is tested and verified that all the various things feeding into it interwork with each other. That stable version is then propagated into the other teams for them to work with.
Linux uses a variation of this. People work off the mainline tree. Riskier stuff is in the -mm patchset, so if you want to play with it you need to sync from multiple places.
The real problem with the scenario as described is the repository organization, likely not in the repository tool. There should have been a way to manually make a child stream that started with the stable version, then pulled in the latest changes from the kernel group, the tabletPC group, and the shell team. That would have allowed them to all work together and see what each group was doing.
Parent
Re:The modern DVCSs would all do better (Score:5, Interesting)
The branching / merging etc in the tool set (which btw we didn't invent, we source licensed from someone else and then have been continually improving) are quite good actually.
I don't know for a fact that the systems you mention arne't "up to the job", but how many multi-TB bitkeeper repositories are there? How many concurrent developers do any of these support? How many branches? How often are RI/FI done? How often do developers sync? What is the churn rate?
I think you also don't understand the problem. The SCCS can RI and FI (reverse integrate, forward integrate, respectively.. those are the terms we use for moving changes from a descendante branch upstream or moving fixes in a parent branch downstream) quickly and efficiently but there are reasons not to. The 99 USENIX paper on the MS internal SCCS talks about some of these issues. For isntance - what good is there in propogating a fix to every sub-tree or branch in a matter of minutes when it subtly breaks 80% of them?
The issue with lots of branching isn't the SCCS. It is the gating that you say "should be possible". Not only is it possible - its standard procedeure. And as your code gets closer to the root of the tree, the quality gates get harder to pass through. The latency involved in turning the crank on a regression test in Windows is very high, and if you got it wrong, the latency of a build is high, etc etc.
So it's not the underlying SCCS, it's the processes built on top of it. Everyone hates process when it slows them down and everyone wants more process when someone else breaks them. "We should put a process in place to prevent that guy from breaking me, but uh, i should be exempt".
As an aside, there are "fast track" branches/processes that let critical changes move through the tree very quickly.. on the order of a day or two from developers workstation to something that shows up in the next main-line build that an admin assistant could install.
When I work with our repository, which is on the order of 10GB and a few hundred thousand files, a new branch create takes a few minutes. Pulling down the repository takes hours. Our churn rate is such that with a handful of developers, ~5 days worth of changes can take 30mins to sync down.
When I RI or FI, it happens only in my client view. This gives me a chance to do merge resolution, and then to build and run our regression tests before "infecting" the target branch with potentially bad code. If building takes on the order of hours (not minutes), you've got latency of hours above the actual RI/FI time. If running tests takes hours (not minutes), you've got more latency. If after a build + test cycle, you see an integration problem, now you've blown a day before you've even found the problem.
I don't mean to say that there aren't problems, i'm just pointing out that like most process problems, this is death by 1000 cuts. The SCCM isn't a key limitation - even for the windows project (at least, not to my knowledge).
What you read was that the SCCm sucks. What I'm hoping to illustrate is that the process is unweildy at times, not due to any particular technology limitation.
Parent
I'm Not That Suprised (Score:4, Informative)
I've read other blogs in regards to Windows Vista, and from what I am gathering the primary reason why Windows Vista took so long to complete was because of management. Philip Su argued how the gargantuan amount of code included in Vista slowed it development dramatically, however I think that this strengthens my point and the point made in this article.
However, I'm not terribly surprised that this occurred for Vista. The higher execs at the company wanted Vista to be a revolution and had a clear and concise goal that they wanted this operating system to achieve. In order to do this, from what I've read, they needed to form many more separate divisions inside of the Windows division to concentrate on small parts of the operating system. This probably sounded like a good idea, but the problem was that none of their work was in sync with each other. Some had more work completed than others. Furthermore, rifts within divisions such as the one present here spurred disagreement after disagreement, that including the decision to switch the codebase of the OS to the one present in Server 2003 (something that from what I understand should have been decided from the beginning). With all of this, it was only inevitable that confusion and miscommunication would occur.
All in all, while I think Windows Vista is definitely more capable than Windows XP and warrants itself a much needed upgrade, I feel that the actual improvements of the operating system [wikipedia.org] do not warrant a five-year delay. Okay, so the compositing manager, networking stack, and audio stack may have needed some time to complete, but five-years? I am not a programmer, so my impression may not carry a lot of weight, but being that Linux and UNIX based systems have already included some of these "future technologies," it becomes naive to deem this delay as acceptable.
Vista: An Enigma Wrapped In a Paradox (Score:5, Informative)
In the past days of clicking through endless options and dialogs to configure things such as encryption certificates, etc I often wondered if this was really better than editing a single line in an easy-to-find text file.
Start menu? Hardly ever used the damn thing. Shortcut keys with and I put the quicklaunch bar off to one side with the 40 or so frequently used programs I use.
Vista doesn't support dragging the quicklaunch bar off of the stat menu and off to one side because it was "confusing to end users." No one seems to have found a registry override as yet.
Vista doesn't handle symlinks properly. It used to be "c:\documents and settings" but now in vista it is c:\users. I see a clever little "C:\documents and settings" shortcut on my C drive. OOOOoo is this a symlink? No? I get Access Denied when trying to double-click. Opening the path via an API however works fine. Go figure.
BUGS. Features? Half-Features? Call them what you want. I think most technical folks that have to work on this know these problems exist but architecturally or bureaucratically they are hard or impossible to fix.
Often on XP, 2000, NT and 95 I would hit control-esc then R for run and type frequently used programs into run. I would say this is just an odd quirk about me and how I think menus take too long and too much work to do something, but now the run area has been replaced with a little place you type in stuff and through the magic of windows desktop search it finds whatever you type in the area above that normally occupied by program icons. The bug? You have to let it search. No matter what. Yeah, WTF? This works great on a home PC where you maybe have maybe 10,000 files. Network drives? Oh no. You can't just type n:\ then hit enter. You have to physically wait a sec for it to pull up n:\ in the list of programs above the start menu THEN hit enter. WOW, WHAT A GREAT FEATURE. No more control-esc n:\ enter for me. It is nowctrl+esc n:\ wait..wait..wait.. enter. Otherwise I get some random program like Notepad. Or Flash. Or Firefox.
On the one hand I can see how the start menu splaying itself all over your screen as you "drill down" to whatever the hell obscure program you need might be unappealing. On the other hand confining the entirety of all programs available to you to a 400x600 pixel window doesn't seem like a good fix.
This is just the start menu. Don't even get me started on the new file explorer, which is the least half-baked area of Vista in my opinion. Does Slashdot have an option for submitting a rant and getting comments? I'm sure I could go on all day.
I take all this as evidence that a lot of new features in vista are based on good ideas.. new paradigms in UI design.. it just seems that the vast majority are implemented poorly at best and implemented recklessly at worst. I would not expect this in 2006 when others are able to produce such polished and solid OSs. I would have to agree this seems like code-rot from the inside out probably due to the megalithic internal structure at MS
...and OS/2 became Microsoft (Score:5, Interesting)
Mountain != Molehill (Score:5, Insightful)
1) There's a power button. That shuts things down fully. ("I am going away from my computer now, but I'd like the power to be really off.")
2) There's a lock button. That leave it running, but keeps others out of your stuff. ("I am going away from my computer now.")
3) There's a menu of choices if you care to look at it, and the button is much smaller than the other two and has a nondescript arrow icon on it which makes it much less attractive to non-techie users.
Yes, his suggestions for combining lock with switch user and sleep with hibernate are good, but I don't think what they actually implemented is all that difficult to understand. His problem is that he's "one of us" and went looking for all the extra options. Most people will never click that arrow to make that menu appear. Ever. It's kind of unfair, even to Microsoft, to rag on something for being unfriendly to non-techies when non-techies are never going to even see it. Usually Joel Spolsky's observations are spot-on, but this time I'm going to have to give him an F for eFfort.
Too much complexity?? (Score:5, Insightful)
Now I'm not a Microsoft employee, but even as an outsider I've seen some hints that it might be the "promiscuous dependency taking" that has delayed Vista.
1) Integration of Internet Explorer.
Microsoft claims that IE and Windows are inextricably linked together, and at least for Windows 2000 and newer this seems to be true. For instance, if you type a URL into the address bar of the Windows Explorer, it will show you web pages. IMHO a stupid design, the web browser should be an application, not a fixed part of the GUI.
2) The RPC service being responsible for things a "remote procedure call service" has no business handling.
In August 2003, a worm called MSBlast spread by exploiting a buffer overflow in the DCOM RPC service (see Wikipedia, http://en.wikipedia.org/wiki/MSBlast [wikipedia.org]). At that time me, trying to be clever, thought:
"I don't want anyone remotely executing stuff on my PC anyway. I'll just switch the service off and be fine".
Lo and behold:
After turning off the RPC service, various local functions were dead as well. Including the Services menu in the control panel. I was lucky that I could reactivate the RPC service by manually editing the registry, else I would have spent a day reinstalling.
So it seems quite believable that Microsoft is choking itself by lack of discipline in designing Windows
Microsoft: Shadow Stalker (Score:5, Insightful)
"In an almost spooky series of events, Microsoft has shadowed Apple's brush with death, making the exact same set of moves exactly ten years after Apple:
- In the mid 90s, Microsoft rapidly built upon its past success with MS-DOS to establish Windows as a vast empire
...just as Apple used the success of the Apple II as a stepping stone to launch the Mac in the mid 80s.
- From 1995 to 2001, Microsoft rapidly delivered advancements to its desktop Windows product
...just as Apple rapidly advanced the Mac System Software from 1985-1991.
- In 2001, Microsoft began announcing technologies that would be released as part of Longhorn and later Blackcomb
...just as Apple described new technologies intended for Copland and Gershwin a decade prior.
- From 2002-2006, Microsoft dropped features, changed plans, and started over several times in protracted efforts to ship Longhorn
...just as Apple had fumbled around with Copland ten years earlier.
- By 2006, it was obvious that Microsoft's Longhorn was not going to live up to the hype, and would really be just a refresh of the existing Windows XP
...just as Copland had been gutted in 1996 and its salvaged remains delivered as the optimistically named Mac OS 8.
- Microsoft outed Blackcomb as vaporware
...just as Apple admitted that Gershwin had never been anything but a list of deferred goals ten years earlier.
What's Next? The only difference between Apple and Microsoft is that today, in the final days of 2006, there is no equivalent to a 1996 NeXT waiting in the wings to swoop down and fix Microsoft's mess. Leopard vs Vista 5: Development Challenges [roughlydrafted.com]Re:Sleep vs Hibernate (Score:5, Informative)
Hibernate writes the RAM contents to disk, then when it starts back up it writes back from the disk to the RAM, and brings up similar to sleep mode.
Sleep is faster, hibernate takes it down farther and shuts power off completely.
Parent
Re:Sleep vs Hibernate (Score:5, Insightful)
Parent
Re:Sleep vs Hibernate (Score:4, Insightful)
Parent
Standard geek viewpoint == standard geek problem (Score:5, Insightful)
Not to most people. Certainly not past a *few*,*salient* choices. Past this point, more choices just add confusion. You do not need 255 different ways to tell a laptop to "close up for later use". A true geek would want to be questioned for each process about whether it needed to be persisted or killed. This is a problematic mindset.
Parent
Re:15 ways to turn off a cumputer (Score:5, Funny)
I bet I know what you use your PC for.
Parent
The Success of the OS is Predetermined. (Score:5, Insightful)
2. Sales/Marketing's job is to force this product down OEM's throats. Good, bad, whatever, just buy it.
3. There is no accept or reject market mechanism. You WILL be buying Vista if you choose to buy a new PC later. It will be the very rare individual who switches to a mac or just slaps linux on their current box.
4. There is no incentive to establish a more productive developer environment.
Therefore, chaos and mismanagement won't ever harm the beast.
Joel's comments are fun to read, but the scale at which MS develops their OS makes it too easy to criticize from Joel's relatively tiny company.
Finally, How many hours did the developer spend/waste reading
Parent
Re:The Success of the OS is Predetermined. (Score:5, Insightful)
Parent
Re:The Success of the OS is Predetermined. (Score:5, Insightful)
Of course, there's still vendor lock-in, which pushes in the opposite direction (decreasing the power of those competitors and increasing the price of Vista), but competition is far from absent.
Parent
Re:Hopefully (Score:5, Funny)
You run Windows Vista on your kid?! Not even Linux users would do that!
Parent
Re:Hopefully (Score:5, Funny)
Parent
Re:Compare and contrast. (Score:5, Interesting)
There is a master "train" for a release; projects that don't change are "forwarded" to that train, meaning no source changes are required. When a project needs to be submitted for a change for the new release, a new "view" is created for its specific changes. Every few days, a build is produced, sometimes using previously compiled bits from the old "train", sometimes its a full world build (which can take several days) but otherwise building all the latest submissions.
Then there's a fairly labor intensive "integration" phase where the built bits are all put on a box and booted. If a "quicklook" QA process shows that the build is hoarked, the integrator goes and pesters the submitters of the latest project that was submitted and gets them to fix it. (Some percentage of the time, the new code has exposed a bug elsewhere, regardless, the project that is the proximal cause of the failure is rolled back to the previous revision, it anticipation that all the projects that need to rev be submitted at once.)
The whole thing is set up through symlinks via NFS, so if you want to see the latest version of any piece of code in the system (modulus those projects that are "locked down" for security issues) you can just get your release name, append the build number, and you've got the source code, symbol'd binaries and build log *for any release* at your fingertips.
When a new build comes out, you just do a clean install. It takes about two hours on the internal network, so typically you pull the disk image and slam it to a firewire drive, (usually, you can bum a disk with the image already grabbed from a teammate) and do a full install in 15 minutes. I can't imagine having to spend a day (as some other posted mentioned) setting up a machine...
Most projects have 3 or 4 contributors. In many cases, and entire framework is the responsibility of a single person (and he or she may actually own several small frameworks.) Lots of small projects produce cleaner interfaces that lead to fewer dependencies. (Of course there are dependencies, and circular ones, but these are kept to a minimum.) Projects are encouraged to use public API from other projects, rather than SPI or other project internals. If there's something useful enough for some other project to use, its first made into SPI for internal consumption, with the goal that developers will eventually be able to use it through a public API.
Most groups don't have dedicated QA by the way - the engineers are responsible for their code, and everyone is generally just very smart about what they're doing.
As to this start menu problem: the entire UI team is about 5 individuals, plus Steve Jobs and Scott Forstall - and they're likely to say "Thats fucking stupid, just do this" and boom(tm), the decision has been made the product ships, and life goes on.
Parent