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. To my happy surprise (where "happy" is the freude in schadenfreude), Joel Spolsky wrote an article about my feature.
I would like to try to explain how this happened.
I worked on the "Windows Mobile PC User Experience" team. This team was part of Longhorn from a feature standpoint but was organizationally part of the Tablet PC group. To find a common manager to other people I needed to work with required walking 6 or 7 steps up the org chart from me.
My team's raison d'etre was: improve the experience for users on laptops, notebooks and ultra-mobile PCs. Noble enough. Of course the Windows Shell team, whose code I needed to muck about in to accomplish my tiny piece of this, had a charter of their own which may or may not have intersected ours.
My team had a very talented UI designer and my particular feature had a good, headstrong program manager with strong ideas about user experience. We had a Mac [owned personally by a team member] that we looked to as a paragon of clean UI. Of course the Shell team also had some great UI designers and numerous good, headstrong PMs who valued (I can only assume) simplicity and so on. Perhaps they had a Mac too.
In addition to our excellent UI designer and good headstrong program manager, we had a user-assistance expert, a team of testers, a few layers of management, and me, writing code.
So just on my team, these are the people who came to every single planning meeting about this feature:
These planning meetings happened every week, for the entire year I worked on Windows.
In addition to the above, we had dependencies on the shell team (the guys who wrote, designed and tested the rest of the Start menu), and on the kernel team (who promised to deliver functionality to make our shutdown UI as clean and simple as we wanted it). The relevant part of the shell team was about the same size as our team, as was the relevant part of kernel team.
So that nets us an estimate -- to pull a number out of the air -- of 24 people involved in this feature. Also each team was separated by 6 layers of management from the leads, so let's add them in too, giving us 24 + (6 * 3) + 1 (the shared manager) 43 total people with a voice in this feature. Twenty-four of them were connected sorta closely to the code, and of those twenty four there were exactly zero with final say in how the feature worked. Somewhere in those other 19 was somebody who did have final say but who that was I have no idea since when I left the team -- after a year -- there was still no decision about exactly how this feature would work.
By the way "feature" is much too strong a word; a better description would be "menu". Really. By the time I left the team the total code that I'd written for this "feature" was a couple hundred lines, tops. [edit: note that that are tons of other more complicated features that support this menu, like the control panel, the additional kernel work, etc., whose code was huge compared to mine. Note also that these features weren't, by a long shot, the only thing all these people were working on]
But here's how the design process worked: approximately every 4 weeks, at our weekly meeting, our PM would say, "the shell team disagrees with how this looks/feels/works" and/or "the kernel team has decided to include/not include some functionality which lets us/prevents us from doing this particular thing". And then in our weekly meeting we'd spent approximately 90 minutes discussing how our feature -- er, menu -- should look based on this "new" information. Then at our next weekly meeting we'd spend another 90 minutes arguing about the design, then at the next weekly meeting we'd do the same, and at the next weekly meeting we'd agree on something... just in time to get some other missing piece of information from the shell or kernel team, and start the whole process again.
I'd also like to sketch out how actual coding works on the Windows team.
In small programming projects, there's a central repository of code. Builds are produced, generally daily, from this central repository. Programmers add their changes to this central repository as they go, so the daily build is a pretty good snapshot of the current state of the product.
In Windows, this 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.
So in addition to the above problems with decision-making, each team had no idea what the other team was actually doing until it had been done for weeks.
The end result of all this is what finally shipped: the lowest common denominator, the simplest and least controversial option.
I have no idea how much of the rest of Vista ended up like this. I think (indeed hope) my team was a pathological case; unfortunately it's a visible one.
edits: fixed link, removed some strong language, fixed math
136 comments:
Wow, the description of the source code management system sounds unbelievable. Are things really that fragmented?
If it does take months for changes to propagate, it's amazing Microsoft can ever ship anything. You'd think the code base would be perpetually broken, or developers would be twiddling their thumbs 90% of the time.
http://digg.com/software/Vista_shutdown_crapfest_1_year_s_work_200_lines_of_code
Nitpick: link to "article" should be http://www.joelonsoftware.com/items/2006/11/21.html for posterity.
Hmm... looks like Office is much better off from the source control perspective.
That really doesn't sound like much fun at all. I thought it was bad when the guy next to me made a change to the database and broke my code.
But not finding out for a couple of months would be horrible. No wonder Vista is so delayed. If everything worked like your team they could stop coding and not have everything integrated for another 3 or 4 months. Only then would they know what was broken. Ouch.
Joel was talking about how sleep and hibernate can be merged. The Mac does this nicely. There is only one choice, "Sleep." At least with laptops, it hibertates the machine (writes RAM to disk) but then actually sleeps. That way, in case the power goes away by the battery wearing down, you just wake up as if you had been hibernating all along. (You can test this by sleeping a Macbook and then removing the battery. I don't feel like unplugging my iMac to see if it works the same way.) And if you never run out of power, you get the advantage of a fast wake-up time.
This seems to be the right solution 90% of the time. For those geeks that really want only sleep or only hibernate for some reason, they can hack away and change the default behavior. (It's fairly easy to do.)
This is why I like my Mac so much. Instead of bogging me down with pointless choices, it just does things the one best way.
Actually, that's not true. Mac's by default to the equivalent of Stand By in Windows, which is that it doesn't write the RAM to disk. If you take out the battery your data goes down the drain. However, if you put it to sleep, and it's sleeping drains the battery, it will go into a "Deep Sleep" that writes RAM to disk before the battery goes completely dead. When you wake it up it'll do a little progress bar and you're back.
I started work at MS in 1986, and worked on and off until 1997.
In 1986 the company employed 1500 people.
In 1989 I worked on Windows UI for a brief period. I think the company was up to 4 or 5000 people at that point.
Even then one could see that what MS did to IBM would eventually happen to MS, and that they would grow to become what they once laughed at.
Too bad. Vista is a bloated baroque thing that adds some kernel security and eye candy at the cost of doubling a machine's RAM and adding a high-end graphics chip.
If Ubuntu or another Linux can solve some of their remaining networking, graphics, and setup issues, they've got a major opening.
-- stan
"No wonder Vista is so delayed."
The "wonder" is that it will ship at all. That'll be a major miracle, considering these development conditions.
Anonymous: Wrong. Mac hits the RAM to the hard drive immediately (it's called "Safe Sleep"). Anonymous before you was right, it's the right behavior most of the time.
"Actually, that's not true. Mac's by default to the equivalent of Stand By in Windows, which is that it doesn't write the RAM to disk."
That used to be true.
http://docs.info.apple.com/article.html?artnum=302477
I'd have to say that this tiny glimpse into the complexity of Microsoft's development process explains a hell of a lot. Hope you all like Vista guys, because it's the last XP service pack you're going to see for a LONG time.
You and other Microsofties should post these sorts of experiences at http://coderific.com/
If these sorts of problems are published widely, maybe they'll realize it's a issue with their organization and get their act together.
Actually in Vista on a desktop PC the default is 'hybrid sleep' which writes the RAM contents to disk like hibernate and then goes to sleep.
So on my PC if it's idle for an hour it goes into 'hybrid sleep'. This is particularly useful compared to a laptop. It's helped me once already with a power failure.
Not sure what the default is on laptops with Vista. I'd guess regular sleep with a wake up at 10% battery level to hibernate makes more sense than an immediate hybrid sleep.
To be precise, when a Mac prepares for safe sleep, it only needs to write out those pages that are dirty, since a majority of the working set of virtual memory is already extant on the disk. It's not like a MBP really needs to dump a whole three gigs to disk as soon as you close the lid.
Thanks for restoring some perspective to my situation. One of your statements explains it for me.
"The end result of all this is what finally shipped: the lowest common denominator, the simplest and least controversial option."
"In Windows, this model breaks down simply because there are far too many developers to access one central repository -- among other problems, the infrastructure just won't support it."
Now wait a second here. This is *Microsoft's* infrastructure which is supposed to support their *most important product*. It should be able to support this and a pony for me, too. Don't tell me that Microsoft can't afford the hardware or the software.
Anonymous said...
You and other Microsofties should post these sorts of experiences at http://coderific.com/
If these sorts of problems are published widely, maybe they'll realize it's a issue with their organization and get their act together.
Joel on Software, the most-read software blog in the known universe, linked to this posting, so I'm quite sure that half of Microsoft has read it by now...
Can't say I'm that optimistic about Microsoft getting their act together, though. How about that Zune, eh? Hah.
The excessive menu nesting in the UI for this feature, the tree of source code repositories, and your description of the structure of teams within MS seems like a pretty good illustration of Conway's Law:
"Any piece of software reflects the organizational structure that produced it."
It looks like the time is nigh for a Finish menu next to the Start menu.
disclaimer - I was a manager at Microsoft during some of this period (a member of the class of 17 uninformed decision makers) although not on this feature, er, menu.
The people who designed the source control system for Windows were *not* idiots. They were trying to solve the following problem:
- thousands of developers,
- promiscuous dependency taking between parts of Windows without much analysis of the consequences
--> with a single codebase, if each developer broke the build once every two years there would never be a Longhorn build (or some such statistic - I forget the actual number)
There are three obvious solutions to this problem:
1. federate out the source tree, and pay the forward and reverse integration taxes (primarily delay in finding build breaks), or...
2. remove a large number of the unneccesary dependencies between the various parts of Windows, especially the circular dependencies.
3. Both 1&2
#1 was the winning solution in large part because it could be executed by a small team over a defined period of time. #2 would have required herding all the Windows developers (and PMs, managers, UI designers...), and is potentially an unbounded problem.
(There was much work done analyzing the internal structure of Windows, which certainly counts as a Microsoft trade secret so I am not at liberty to discuss it)
Note: the open source community does not have this problem (at least not to the same degree) as they tend not to take dependencies on each other to the same degree, specifically:
- rarely take dependencies on unshipped code
- rarely make circular dependencies
- mostly take depemdencies on mature stable components.
As others have mentioned, the real surprise here is that they managed to ship anything.
How does this compare to your new gig at Google?
Do you feel like G's doing a better job with scaling (the company, not the software), or do you think they're inevitably going to end up with the same bureaucracy? It's hard to believe that they're doing much better if they're hiring 100 people a week, despite all the hype...
Roman Werpachowski said...
> Now wait a second here. This is
> *Microsoft's* infrastructure which
> is supposed to support their *most
> important product*. It should be
> able to support this and a pony for
> me, too. Don't tell me that
> Microsoft can't afford the hardware
> or the software.
It's their setup that's all wrong, not the cost of hardware or software. The current source code management setup in Windows was introduced by Mark Lucovsky (him who Ballmer threw a chair at when he announced he was joining the big G). The VCS is called SourceDepot and it's a modified version of Perforce.
As someone else pointed out, dependency management is Microsoft's big weakness when compared to Linux. This manifests itself in the complexity of version compatibility with beta versions of software (see the VS CTP compatibility tables on the web). It also manifests itself in the horrid MSI-based security patching that Microsoft use. And as someone said, it manifests itself in the internal build process. If you can't run a static dependency checking analyzer over your dependencies, then you have no idea whether a build will succeed or not.
It's also worth noting that SourceDepot is a conventional VCS, whereas the Linux kernel and most of the large open source products (Java, Xen, etc) use a distributed VCS. I've never used Git, Bzr, Mercurial, or any of the other systems to know the advantages over a central, non-distributed system. Perhaps Microsoft should have given them a go?
I'd like this:
start and stop
[team of one -- 10 mins.]
This Microsoft all over; a top-heavy ship with no rudder.
The problem with bad management is that the only people who can sort it out is the managers themselves - everyone else just grumbles and puts in the minimum effort required to keep their jobs. This makes the mangers feel more justified that everything needs to be micro-managed, where in fact they're the cause the problem.
The best way to resolve this is lay off the managers and of course they want to hold on to their jobs. It's a tough problem and for or as long as MS continues to make obscene profits, it's not one they're going to work on solving.
Apple was in a similar situation back in 1997. They were going under and had to radically reorganize. The results are self-apparent.
I now fully appreciate the flat management structure at my company...2200 employees with a maximum step to the chairman of 5 layers. No wonder MSFT stock chart looks like a dead patient ekg.
Sounds like the Mythical Manyear all over again.
What they make up for in innovation and telented engineering they make up for in $ and PR spending.
Let's face it, it's cheaper and safer not to innovate, just see what's working, try to duplicate it, and by advertising.
I'm sure a majority of their engineering will be farmed off to a third world in short time.
While I have no real problem with the shutdown menu, I can see how it would be confusing for some less experienced people.
But that doesn't excuse the amount of time wasted on what should have been a relatively simple decision. But it doesn't come as much of a surprise. All too often management gets in its own way.
It's too bad that MS can't be a little bit more agile in its product development.
Disclaimer - I'm a current dev on Windows.
It's absolutely true that a deep tree tends to increase the time it take a piece of code to migrate up to root and back down to farthest out branches - but that's not the problem. Slavish adherence to the "rules" as a means of CYA, a desire to build kingdoms (people/hardware/process), an inability to adjust as circumstances changed, and an irrational fear of breaking "something" were the real problems with many branches in Vista.
So what if you were 4 steps away - that's exactly where you should have been if you were working on a destabilizing area with a small team. However, once your code was relatively complete - your branch should have been orphaned and you should have moved up one level - if necessary, creating another branch 3 steps from root. And when that branch was essentially done, you should have moved 2 branches from root. If you had to take on destabilizing changes again, you go down a level. The key is to be flexible, be aware of where you were in the dev cycle, adjust accordingly, and understand the REAL impact when something breaks(every break is not the same). Some teams managed to do exactly this - many didn't. This isn't difficult - but teams constantly harped on BS "rules" as the reason why they couldn't move or make progress. "My PM tells me what bugs I can/can't work on". "I can only check into branch vvv_www_xxx_yyy_zzz - I have no idea if/when my changes will migrate up". "We need a N-week test pass before we're allowed to make a change - there's no way we could do that in any other branch".
I see exactly the reverse happening now. "Deep is bad" and "Every branch should be off root" are the new mantra. It will result in failure as well because it fails to take into account how software is written under some belief that "this time it's different". Depth protects the root early in the cycle, allows batching of destabilizing changes (and more importantly dev/test/triage resources). It will fail when a milestone approaches and every branch wants to integrate up at once. It will also fail as everyone will feel the need to 'bulk up' so they can run off root - and once you do so, it's incredibly difficult to ever slim down.
What kills me is that you don't have an RSS link on your BLOG.
I'm really, really surprised your code ["feature"] was accomplished with -so- few people involved!
My unfortunate team has ~70 people chiming in on pointless discussions exactly as you mention... yes, that's PUMs too.
Talking with all industry contacts in IBM, AMZN, et al., no one experiences this except us. :-(
UI programmer job is pain. Because everyone can say something to it. You keep changing UI but still can not please everybody.
Is this true: 1.5 year for XP sp2 and 1.5 year for testing/dumping winFS, thus 3 out 5 years wasted together for the final vista?
To the anonymous manager: So instead of fixing their fucking mess of interdependent libraries and whatnot, Microsoft opted for an incredibly byzantine build system? That's an "interesting" decision :-)
If this was development, what was security like?
That could go halfway to explaining why it takes MS half a year to respond to Real Life events, no?
I know exactly where you are coming from on this. I work for a small UI design company that worked on Vista from 2002 until 2004. Microsoft wanted to avoid some of the problems that cropped up with XP and told us they were going to do Longhorn "right" this time. After years of slaving away to supposed exacting standards of UI elements, the project was pulled from us and (I assume) taken in-house. Perhaps it was outsourced to cheap labor...
Now we see the result and I can tell you it is not pretty. UI elements look as though a child designed them. Inconsistencies are apparent everywhere. Elements from XP are STILL present in the OS and in some cases have been band-aided to fit Vista parameters instead of redesigned from scratch.
Microsoft is in a heap of trouble and these two examples are good reasons why. They have no true focus on their products or how to design, develop and produce them to compete with the cutting edge. They have become bloated, slow and anything BUT agile. Its sad, but true.
I am able to configure my own concept of simplicity at:
Control Panel/Hardware and Sound/Power Options/Change what the power buttons do
That´s OK with me.
MS has been consistently crap since Win1.0 through WinXPSp2, full of bugs and flaws requiring constant "patches". Why then does corporate Amerika continue to stick with this loser? We are in deep trouble.
I find it funny that Vista, with a few thousand programmers (after reading this article, I wonder how many of them actually program!) is so bogged down in bureaucratic crap that its years past target date and horribly buggy, while Linux, which has many times the number of programmers spread out around the world, can develop at a rapid pace a product that is infinitely better. I guess this is just a perfect example that the Cathedral style of software development belongs to history books, while the Bazaar style is the way of the future.
P.S. If you have never heard the terminology in the previous comment, read catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/
The tiering of the source code is not a new approach, people have been trying things like that since the 70s, and always come away with the firm conviction that the people before them were right (you shouldn't do it). It is an encoding of the very saurian project management that toppled IBM.
The solution is out there, and has been, for some time. I'm not talking about a specific instance, because frankly I've grown to like SourceSafe for the way it handles cross-dependencies (links).
Its a three part solution: 1. RCS style branching (where branches aren't repository copies), 2. encapsulation of the tiering within the source control environment, 3. automated acceptance testing.
Many game development companies use a technique whereby developers can check in code that might break the project only to a new branch; this gives them opportunity to share a change with a limited pool of other developers who have to write the code neccessary to complete it. When the project is done and ready for review/testing, they merge the branch up *themselves*.
The source-code system then performs acceptance testing on the code changes when you try to merge a branch. That is, it tries to build the code base that would result, and refuses the merge if the resulting code won't compile.
IMHO the real issue is much simpler than any of this; its a problem that every software developer working under Windows gets to share in the agony of: Microsoft allows itself to blur the line between its products. While I realize that the programmer who decides to make a particular change is probably trying to Do The Right thing, it seems to be that decisions get *approved* for different reasons. Tweak the OS here to make something in Excel cooler ought to only occur when that tweak is generally good for the OS. But its always been emininently clear that a small degree of cross-pollution goes through because somewhere in the chain Windows and Word, Excel, Access, SQL Server, IIS, .... all deposit into the same accounts.
The guys working on Visual Studio rank amongst my developer heroes; it's a fantastic IDE. And I know most of their team have aims and goals I consider righteous. But it scares me silly that they might have the ability to influence the OS any more than any good programmer suggesting an idea to the OS/dev team should have.
I also think Vista suffers from Mac-reverse-engineering (not literally, as in of code). The Mac's UI is clean because its a top-down design of simplicity. Vista has a shutdown crapfest because someone had already broken the Mac design paradigms. So looking to the Mac for closure was like a team of specialists trying to make a menu more appealing by finding 15 different names for boiled cabbage soup.
I think you should have thrown the Mac out and said: the Mac would never do this but how are we going to do it well? (I'm sure that you did do something like that, but you get my point :)
Thanks, Moishe, for the great insights. We had recently written an article, trying to learn from this situation, so that product managers can avoid it in their products. Your insights really help us understand just what it was like. Our article, at Tyner Blain, Fifteen Ways To Shutdown
So Joel Spolsky slips back into a Microsoft Program Management (PM) role and decides to write a spec for the power button on the Vista Start menu. The reason he spent the time doing this is because he felt the number of options provided, 9 were excessive and confusing to most users. His spec comes down to:
"So now we've got exactly one log off button left. Call it "b'bye". When you click b'bye, the screen is locked and any RAM that hasn't already been copied out to flash is written. You can log back on, or anyone else can log on and get their own session, or you can unplug the whole computer."
Now if Joel actually clicked on the Vista Start button and then looked at the options presented before expanding the 'advanced' list of options then he would've realized that in fact the implementation in Vista is virtually identical to what he ended up specifying.
To the normal user there are really just 2 options, a 'Power' button and a 'Lock' button, which have tool tips that explain what they do.
Now on my desktop PC with a default install of Vista the Sleep option is a new hybrid sleep implementation which is really a combination of hibernate and sleep. When the PC goes to sleep, either based on an explicit user request or because it has been idle for 1 hour then Vista writes out any necessary RAM pages to disk as it would for a hibernate, but then instead of switching off it goes into sleep mode. The advantage of this scheme is that if there is a power failure (environment, cord unplugged accidentally or on purpose) then when the PC is powered on again it performs a hibernate resume. I've actually experienced this first hand with a recent power failure and it was really useful to get back to all my open applications etc. after the power failure.
Now in addition when the PC resumes from sleep in this scheme you are presented with a login screen, and if Joel had taken a look he would've also noticed a 'Switch User' button on this logon screen just below the password edit control.
So this default scheme is pretty darn close to what Joel has specified as his ideal UI, it really just has 1 extra option, the 'Lock' button.
The main issue I think is that Joel hasn't approached this as 'regular' user, but rather more as an advanced/power user who has decided to click on the advanced list which is shown when you click/hover over the '>' button. So Vista has provided the simplicity for regular users and has made an advanced list of options available for more advanced users. Now what may have been a more useful posting/debate is whether this advanced list is too easily accessible to regular users by accident, e.g. should it maybe only show up if say the 'alt' key is held down like a lot of the menu bars in Vista applications.
I think one of Joel's unstated points was to question why there "Advanced" options exist at all.
"I think one of Joel's unstated points was to question why there "Advanced" options exist at all."
This is easy: when you have close to one Billion customers, assuming they all want the same thing is a false assumption and unnecessary 'simplification.' This is also part of why Windows has close to 1B customers instead of the Millions of Mac customers.
I agree with this:
"So this default scheme is pretty darn close to what Joel has specified as his ideal UI"
Much of this feels like whiniy 'holier than thou' design critique designed to generate web traffic and attention. Designing UI is non-trivial and it's always easy to tear down any design if you change the customer expectation.
What's hilarious is reading all the comments from people who didn't even have a clue what Vista's default behavior was but felt certain it must be wrong because they are Joel groupies and his word is law. Spolsky is incredibly overrated (and overrates himself) on UI subjects. The man has no real training in ergonomics but believes he has genius insights. He doesn't, he's a guy on a barstool and thinks he knows everything.
When the managers working on the project outnumber the programmers, you know you're doing something wrong...
"He doesn't, he's a guy on a barstool and thinks he knows everything."
Said like a true know-it-all.
"...This is also part of why Windows has close to 1B customers instead of the Millions of Mac customers."
I can't believe anyone let the above statement rest. Either it sits too far down the list for most people to wade through, or we are just getting tired of correcting such glaringly wrong statements.
We know the reason for the obscene market share...the only thing worse than a Microsoft Apologist is a...
well, you're gonna have to give me some time on that...
helios
I am just a humble user, but the situation described in Moishes's blog does not surprise me in the least. It confirms what I expected after using XP.
It sounds like an exemplary illustration of the proverb "the road to hell is paved with good intentions".
It also the explains why MS avoids real-user feedback, because it taxes a system already on the verge of meltdown. My cable company (ntl) had the same problem not too long ago and it was only change in management at the top that saved them.
Extrapolating, I would say the management system needs over hauling from the top down, its too cosy at the top, heads must roll and fresh thinking must be allowed to make a difference.
As a result of poor management the design strategy is clearly not providing a clear lead to programmers and developers. The thing I like to do with my XP system is play games, from what I know of game design, its vital that the design comes first and the game is completed according to the vision in the spec, so that the result has coherence. You can't complete a piece of work if you keep changing the spec.
My diagnosis is that MS bites off more than it can chew, the management philosophy aims for the sky but misses its footing, instead of grandiose revolution MS should be aiming for reliable execution.
Well, everybody is giving an opinion ... I usually keep my own to myself in a situation like this. But a some things burn ...
Sure, Joel is usually talking plain gimme-traffic garbage. Every once in a while he says something that is really worth considering. But the net is such that one single good shot makes everybody (you included) think you rock. I don't know if he knows that his web page, for example, is the single most crappy piece of user interface design, with some kilobytes of a monotonous string following you everywhere you go, declaring how much he writes FogBugz. It's stupid UI design, worse than being given 1000 ways to get to his blog.
But Joel is right on this one, I think.
The more the choices, the more the simplicity dies. And we all like simplicity. It's why your monitor, for example, is designed the way it is, despite having the possibility of up to 20 options.
On MS' problem, well, I think the problem is programming in 2006 as if we are still in 1960.
This CVS claptrap was for back then, when the worst that could happen was that you had two dynamic files to carry around.
We should be programming in a completely different way. Never have to sync source. Every single build should be able to work with any other single build without effort on our part, or the effort will become to great to make.
That's how computing has become, and it will get worse. The sad part is that the MS people who have the power to change how the whole world programs are not doing that. And their laziness is here to eat 'em.
I can't wait to try Vista now.
it's a good point that the default behavior is close to what joel describes, but the assertion that the plethora of "advanced" options is why windows has so many users compared to the mac is just silly.
the other thing that's silly is calling these "advanced" options. do power users really need or want the ability to choose "switch user" as opposed to the incredibly essential "log off" in this manner? is it something people would miss?
i think os x provides a good example of how to tackle this problem. the fast user switching is both intuitive and useful. by default, it's not enabled. most people have one user on their system, themselves, so it's not needed. for those systems that must be shared (like our family computer that my kids use) it's trivial to enable it, and then a user menu shows up in the top menu bar that lists the users. switching from one to the other is easy enough for a 5 year old.
the point is that this is not an "advanced" feature, but a feature for a specific context. so the better approach is to make it easy and obvious to use in that given context.
as far as sleep/hybernate, i have to go with joel on that one. the computer is smart enough to manage this. why would i want to fuss about it? give me a control panel to alter behavior, but the menu items are pointless.
ui design is difficult, and it's something people (like me) specialize in. and though joel may not be a specialist, he has the right idea. question the utility of each thing you add to the ui. if it's being done to address a need for 2% of users, you better think very carefully about how it can get in the way of the other 98%, and how much you're spending in the way of resources.
after reading this post it's hard to argue with the fact that something's broken at m$.
I thought the text-heavy UI and the ubiquitous mini-bio on every page of Joel's site were SEO strategies.
please, like linux isn't riddled with 'advanced features' that are initially hidden.
I love how people love to rip apart MS. It is so damn fashionable.
I wouldn't worry about Joel.
All things considered, Joel is a moron. In his world, it is OK to remove features and choices simply because most people are stupid. Then again, as I've already stated, he himself is stupid, so I can see where it comes from.
Let me elucidate. Joel is upset because there are too many ways to shut down a computer. All these choices, he argues, makes people frustrated. (They don't, apparently, keep people from shutting down their computer, however.) To remove frustration, which is only after all rooted in ignorance, he advocates removing options. For example, since most people don't know the difference between "sleep" and "hibernate". What's the solution? Educate the user? Provide better context? Add tooltips or flavor text to each option so the user can decide which is best for them? Nope, his solution is, of course, to simply remove the distinction. Let the computer decide whether or not to sleep or hibernate, because all users are the same and use computers the same way, and ultimately because "the computer is smarter than you are."
Well, my computer is *not* smarter than I am, though Joel's may be smarter than he is. My solution would not be to give users like Joel less computer choices, but for him to gain wisdom over that of his inanimate machine.
The fact that he designs and writes software for use by humans -- ugh. He advocates dumbing down the computer to save the dumbed-down users, keeping them dumbed-down. I guess keeping users dumbed-down in turn encourages the market for dumbed-down interfaces, keeping Joel in business.
I can't speak for Vista or it's shutdown menu, but I can speak for the intelligent computer user, who does not suddenly go cross-eyed because he has more than one way to turn off a computer, or half a dozen other distinct functions.
I'm not a sw developer. But the comments here have been real insightful to me, for understanding a lot of modern day subtleties of big sw projects.
From a user perspective, I think some of the posts miss the boat. It's not about making everyone with an opinion happy. It's about leading the masses to goodness. We just want to be told where goodness is. Sure people will complain. But if you're right, then eventually everyone will grudgingly agree. I don't want a product that reflects a current "everyone agrees" decision.
I want something that reflects vision and smarts. Something that incorporates brilliance that I don't have. That's what I would pay for. Of course people might complain at first. Because they're wrong. Eventually, if the product is right,
they'll agree they were wrong.
It's all about being right and moving to a future good place.
Basically I think the MS developer should have taken more chances. Just do the right thing. Risk getting fired. In a big organization, you don't have to fight the bureaucracy. Just act...bloat is incapable of fighting back.
-hw developer
I can't believe Joel suggested removing restart. What if you want to restart the PC into Linux or OS X without turning off and on again? ;)
For the Macs it depends what machines you are talking about:
- For anything pre-Intel then the stand-by mode is a typical battery-backed main memory.
- For anything Intel based, notably the MacBook Pros then you have the typical stand-by mode coupled with a save to disk. This means depending on the situation the Mac will either use what's already in memory, or the saved image - the latter is used if power is lost while sleeping.
"To the normal user there are really just 2 options, a 'Power' button and a 'Lock' button, which have tool tips that explain what they do."
Then why are they dublicated in the advanced menu? Take lock for instance why whould the advanced user need that option in the menu when he can just push the button (which is right next to the menu)?
And I am not convinced that the advanced menu is needed if the software will choose the correct option when just pushing the off button (with feature picking in the control pannel to customize behavior).
I found the description of the "partitioned" source code management setup to be illuminating, because it explains a major issue: monolithic design.
I've worked in other environments where code integration was fraught with peril, though the actual population of developers was small enough that they'd be "right there" for integration & test builds, confirming that their changes didn't disrupt the working of the target system.
Consider that Linux, despite being a "monolithic" kernel, has a fair degree of compartmentalization between component parts-- syscalls, devices drivers, etc-- and the GUI isn't part of the critical code of the operating system itself.
It has been argued that Windows has the GUI integrated into the kernel to ensure that it *has* to be there, despite the roots of NT being from DEC VMS, which means that *any* change by a wide array of developers, once integrated into the "build" system, can create an "unbuildable" system... and, with the number of changes potentially being integrated on a daily basis, I'd bet that they don't want to call in all of the authors of the daily change set together to work out which code "broke" the build since this'd be a daily "critical" call.
When the S/W you're doing builds for doesn't have a sh!tload of cross-dependencies (i.e. "small kernel" and lots of user-level apps) this isn't as much of a problem.
Way back when on the UNIVAC mainframes we had source control via the SSG processor and sidelines consisting of PCFs and TCFs that would be merged into our builds and it took a while for a sideline to get merged into the "main" TCF (Temporary Correction File). It could take months or more for your fixes to be merged into the PCF (Permanent Correction File) and, to my limited knowledge, I'm not sure any changes ever got graduated to the MAIN (root) code. This system also maintained several levels of fallback...
...but that was a much smaller system which had much better code compartmentalization than we have been hearing about.
New Orleans was poorly compartmentalized, by the way. I think we can see why security breaches are so dangerous w/ Windows.
Providing pointless options does not bring you customers; most Windows licenses are bought en masse as a result of corporate purchases, not as a result of individual choice. If you don't know that, you don't know the first thing about how the Win vs. Mac marketplaces differ.
The goal of limited choices is a good one but like everything about UI design or programming it is not dogma.
What really gets me about the sort of UI gurus who like to pontificate on the net is that they take a generally good practice and then take it to ridiculous extremes.
Simplifying the shutdown/restart stuff is a good idea. I like the way the mac integrates sleep and hibernate. Three options in the default configuration: sleep, restart, power off are good. One certainly wants to reduce the number of apparent options but trying to remove restart is just silly slavish devotion to the rule of 'remove options'.
I mean more options are only a problem when they are apparently salient options. If I know I want to step away from my computer having to choose between sleep and hibernate might cause confusion. But when I go to the start menu I have a definite idea about whether I want to restart or power off so what's the problem.
Also the idea that being usable for my mom means it has to be frustrating for a power user is just dumb. Additional settings that allow more options to be displayed or advanced menus are good things so long as they aren't *salient* options to the regular user. Once again the Mac is a perfect example of this. I despised Macs for a long time because they were just too dumbed down but with OS X they manage to retain the simplicity for the average user while combining it with the control and features any UNIX hacker would love.
The problem with things like advanced options in most software programs is that they aren't used consistently. Too often the normal user has to go to the advanced menu to do something. Then once you've sent the user to the advanced menu for one thing it is too easy to achieve false simplicity in your main menu by shifting functionality to the advanced menu that normal users need.
I get the feeling what tends to happen is this. Some UI guy applies the generally good principle of simplicity and tells the menu design people that they have too many options and need to get rid of the restart option. They take his advice but knowing that forcing everyone to power on and off would really annoy some people (especially if the physical on switch isn't easily accessible) they shift it to the advanced menu. Now all the normal users who want to restart look around and when they can't find it look in the advanced menu. But now the advanced options are no non-salient, normal users realize they need to look there for basic functionality and now they are made unhappy by all the confusing options there.
While no rule should be followed slavishly I think there is a good rule of thumb for this. If you can imagine your grandma saying, "How do I just X" and you answering "go into the advanced menu and click X" then something is wrong.
--
Ultimately the real lesson I'm learning from all these comments is that you really need dictators. Whatever solution one guy comes up with for the menu is going to be better than what the committee comes up with.
This isn't incompetence. This is "bureaucratic competence." This is featherbedding at the highest level. This is job security for management. This is facade management. This is programmer boredom. This is disgraceful. This is the beginning of the end for Microsoft.
P.S. - Why can't someone or someones sit down, right now and invent a better operating system and present it to the pc oem's and pc users? Why? And, why isn't that someone Linux? What's the problem here. It's time to get going!
Code control and management issues aside, what is really lacking IMHO is a product manager who has a clear vision of what the UI should be *and* the ability to dictate the requirements to the various development teams. In all the red tape MS seems to have forgotten that the interface IS the product.
have you fixed Math? really? what is 17? perhaps you meant 19? no?
(6*3)+1 == 43 - 24 == 19
Another good joke.... "A Tree of repositories" hahahhahaha, you mean there is too many people? too many commits a day? or is it because you are using Microsoft Source Unsafe on a Microsoft Plateform.
try out Subversion on a Unix system it won't ever be a problem. check out the KDE team for an example. they got tons of daily commits.
The pile of cards is rumbling and shall disappear
Linux really has to take advantage of it. KISS : Keep it simple and stupid, explains why linux doesn't sink under complexity.
I'm not sure it's the chance for Linux, but for Mac it is. Still, the old lion has the media power, and will keep it's share of the cake, but which one?
-> (web)Servers are gone
-> Scientific apps are gone too
-> Geeks/Hackers are gone too (well, only for bughunt purpose ^^)
-> Office apps are getting online
-> Specialized apps are going linux too (custom UIs for custom purposes)
-> Security/High performance is gone too
Remains:
-> Hardcore nerds/gamers
-> The_too_old_to_change generation
-> The i'm_stuck_in_MS_Circle because i don't understand a thing
-> The GIANT shareware field and various MS-bound devs
We shall see the end of Microsoft, maybe sooner than we thought.
Thank a lot for this glimpse of the upcoming entertainment.
Regards
And thanks for this full disclosure
Good Lord! I'm running a few lines of code through what passes for my mind, and you're right - it could and should be done in a week. First draft, handed over to the torture-testers, and then rebroken and rebuilt until it laughs in your face!
and 200 lines for a whole year!
Read "The Mythical Man-Month" by Brookes, if you haven't already. It sounds like you need it.
IMO the only reason Linux (or similar) has not overtaken Windows is that it is programmer friendly, not Joe-end-user friendly, and particularly not gamer friendly. People will continue to use Windows as long as it is the OS of choice for games at home--just as they will continue to use it in business as long as it is the OS of choice for office suites. Even though it is bloatware and everybody wants a better choice.
Keep sleep and hibernate separate.
Sometimes, I want to keep all my open programs, but not use the battery (i.e. I want to use the battery later). I don't want the computer wasting power for a while and then saying "hey, let's hibernate!".
Also, the keyboard is not always available (Tablet PC owner!), so you can't assume I have access to all the keys except for the power button.
No one is forcing you to open the advanced menu. I only seem to be seeing "experts" debating on the relative merits of having many options, not true n00bz. That's like a bunch of guys debating on the merits of pads as opposed to tampons. n00bz don't care about all these options and they'll just press the power button, like I told my mum to do.
For my use, (on a Mac), "switch user" is one of the features we use the most. You have to enable "fast user switching" before you see that, though. I think this illustrates a couple of things. One, this thing that "no one would ever use" is a valued feature. Two, you don't have to make every possible valued feature available from the same menu.
I don't think it's obvious how to fix any of the fundamental problems here: (1) windows code has too many cross dependencies (2) ms working groups are not all up to speed on how/when to move their particular bunch of code to higher nodes (3) there are many different things a user may want to do when they are finished with a session, and it's tricky to make everything available to those who want it without cluttering the environment for the casual user.
Fixing (1) without rewriting everything from the ground up and without breaking every application out there would take an act of God, I would think. Maybe if MS had accepted Dr. Dos' existence back in the day or OS/2's existence, there would be some reasonable separation and industry-wide agreed-upon standards that MS could agree to keep working, and all bets off on anything else. As it is, their own code, as well as the code of whatever other important software vendors there are out there, probably depends on "something in the goo" in many, many places.
(2) is a little more attainable, but it would take someone at C-level to push it through the company I would think, or at least someone within a couple steps of that.
Doing something about (3), well, they might be able to copy the Mac again. But even with the mac--can we say they have it "right"? Is the fast user switching option easy enough to find? I guess with blogging, anything interesting will come out, so what you should probably do is make the most useful options visible and on by default, and figure the blogosphere will bring the other ones to everyone else's attention.
Anyway, good luck rewriting everything, MS! Maybe there's some way you could, over the next six versions, pull individual parts back from each other and then start being able to have some clear separation of functionality. I think Ubuntu's bug #1 might be fixed by then, though.
Thanks for this interesting insight. I was involved with the design of the Shutdown feature in Mac OS X and I don't think we quite reached the design pinnacle we could have. I have posted some background on how we ended up with what we have today here: http://arno.org/blog/2006/11/design-of-mac-os-x-shutdown-feature.html
Thanx .
As your average dumb user , found all of this very interessing .
Guess a full generation of users grow up on win .
Change OS kind of stressing .
Very interesting read. I do wonder what the original motivation was for keeping two buttons on the screen was.
There are a few differences:
In locked mode, your email still arrives; your documents keep printing; your code keeps compiling...
In sleep mode, everything is frozen. Restoring to the previous state takes 2 seconds if you're asleep, and up to 20 seconds if you were hibernating. And it conserves a little power if you're on a laptop. Then you have to restart all your printing/compiling/emailing...
You have very distinct capabilities that people want. So you can (a) not give them both capabilities and simplify your UI to one button (b) place the Lock functionality elsewhere, although it does logically belong next to the Sleep button, or (c) rely on users knowing Ctrl+Alt+Del, which I assume is something MS wanted to 'fix' for Vista.
If you're at home or you've got a personal laptop, you really just want one big "b'bye" button. If you're at work, and will happily leave your computer in an unlocked room, you'll want to choose between the b'bye button and a lock button.
The description of engineering practices sounds like a mess when Microsoft bit off more than it could chew with 1000s of developers using the same process of checking in code. Something tells me they'll try and fix this for vNext...
But the design philosophy (based on what I can guess) sounds totally rationale and the best choice for Microsoft's customers, absent perhaps the hiding of the Lock button for the Home Editions SKUs.
I'm curious to try a Mac to find out how Apple promotes locking their computer...
While the notion of "If you can imagine your grandma saying, "How do I just X" and you answering "go into the advanced menu and click X" then something is wrong. " is appealing, when you're dealing with a billion users there are enough grandmas that someone's asked "How do I just X?" about every feature. This is the very problem Microsoft has, not the solution.
As the same poster went on to say, the solution here may be a dictator rather than a democracy. Of course, that strategy can lead to complete failure, too.
This situation is similar to any large-scale statistics gathering exercise. When you're polling people on everyday issues (e.g. television watching habits), lots of people think they're weird, and that their inclusion in the poll will end up skewing the results. The truth is that everyone is weird, and not including a person's individual weirdness would skew the poll!
In this case, I very much appreciate having distinct Sleep and Hibernate options. Opening a sleeping laptop to find that it's battery is nearly dead is an awful thing, but cold-booting seems wrong in this day and age. If I know I want to save my battery, how is the computer smarter than me by using the battery to preserve RAM contents? But then again, my usage is probably weird.
What would make me happiest is reasonable defaults with no visible advanced menu. The advanced configuration should be in the control panel and let me determine the meaning of the start menu buttons as well as (ideally) adding to or removing from them.
Unfortunately, this really isn't ideal for Microsoft, as having the same button do different things on different systems is ripe for confusion, and asking every user to be their own UI designer leads to terrible UIs that the authorial users themselves often don't like.
The funniest thing about this entry is the commentary. Many lament the 43 people needed to get a "easy" shutdown interface designed.
Yet, here you are in the comments, hundreds of people bickering and getting up in arms about how this should be designed, many with strong opinions.
Guess it wasn't that easy after all, huh?
The problem is that no one seems to have final authority. This isn't about MS vs open source. When Mozilla was designed by committee, it too was an unwieldy, bloated mess of a program. When hijacked by the Firebird/fox/wombat/foo founders, it grew by shrinking and its quality has quadrupled.
The real problem for the Windows world is that no real added quality has arrived since NT4 (which in turn really had only two major things over 3.51, a new UI which was clearly better, and graphics in kernel space which is debatable depending on role). That's very close to zero progress in ten years, folks. Heads should roll at Redmond.
This story makes me really glad I work in a company with only 3 developers and I really hope I'll never have to endure what you went through.
Afterwards it is easy to say that this feature took over year though it could have been done in a week. I am sure you could have done something in a week but I am also pretty sure that you would have been forced to fix that for over year. When I read your story it was obvious that shell team and implementation team had different opinion about the feature and as long as the situation stays like that nothing will be really achieved, it is just a ping-pong between two teams. Maybe the root problem was not the way your team worked but the way teams cooperated?
Wow my friend... That is a lot of bureaucracy.
Regarding the vast number of managers at Microsoft, I'd suggest that they take a leaf out of Sun's book. Sun had a similar problem a few years ago, so introduced the "Rule of Seven". If a manager didn't have a minimum of seven direct reports, they had the choice of merging their section with another so they had an adequate number of reports (staff), or of stepping down as a manager and becoming a "Specialist". My then boss took the former of the two options.
It might help Microsoft to adopt a similar approach, but I'd also be concerned that they haven't a clear target. Getting rid of reams of management will help to clear the mist, but they really ought to identify exactly where they're heading first.
[i]The people who designed the source control system for Windows were *not* idiots. They were trying to solve the following problem:
- thousands of developers,
- promiscuous dependency taking between parts of Windows without much analysis of the consequences[/i]
Why don't they do some "pipelining"?
For example, have a kernel development team that constantly builds kernels without worrying much about anyone else. When the kernel is complete/stable, they pass it off to the next stage of the pipeline, and start the next version of the kernel.
Then you'd have other teams doing the same thing - a GUI team repeatedly writing/adapting the GUI for each new kernel that comes down the line, a few teams doing "legacy" APIs, a few(?) teams doing drivers, etc.
At any time you could have several versions of Windows coming down the pipeline, but at each stage the "foundation code" that each team is relying on is (mostly) stable, static code, so they don't need to be constantly adjusting their work because of changes made "upstream".
At first glance this looks like it'd effect flexibility, but if there were 3 stages on an 18 month cycle, then it'd only take 3 years for a new feature to go from "kernel team sign off" to a released product with the new feature (better than consumers see now), and you'd be releasing a new version every 18 months (much better than consumers see now).
Anyway, in this case you'd have a source control system for each stage, and half the dependancy problems wouldn't occur to begin with.
Of course there would be practical problems with this (especially with a monolithic "everything including your grandmother" kernel), but Microsoft do seem to be aware of these sorts of dependancy problems, and do seem to be at least attempting to fix them.
The best way to resolve this is lay off the managers...
That will leave you with still too many different teams, and they'll still be working at cross purposes.
The real solution, and what Microsoft *should* have done about six years ago, is to recruit about a dozen of your very best programmers (note here that "best" does not necessarily mean "smartest"; they have to be motivated and cooperative, so that they're able to work as a team under just one manager, and at least some of them need to have a good understanding of how end users think), take them off to the side, start them from scratch with nothing, and have them implement, from the ground up, the next version of Windows. When they have something complete enough to port software to (should be about 2-4 years from the project start, if you don't let outsiders to the project interfere and interpose agenda items; this works best if only about three people outside the new team itself know it exists), you grab another half dozen programmers and put them on a team tasked to take the Virtual PC product that Microsoft acquired a while back and port that to the new OS. You're going to sell it as a bundle, with a copy of the old OS running inside the VM, for the purpose of running legacy software.
About the same time that you start porting the VM, you also start working with ISVs to get some software written for the new OS. About a year later you ship a public beta of the new OS. The total time elapsed is somewhat less than Vista, and you have a new, clean codebase with its own small team of developers and one manager. Everybody on the old Windows team, except for a handful of security people, can then be reassigned to, umm, the Zune team, or something.
I've just discovered your article and I have to say that it's very good. I guess your pov is very assertive and I agree with you.
Excellent blog. Keep workin' that way.
Nice post. Quite nice.
For me this post not about "Sleep/Hibernate" feature at all. I think this post is about management.
I heard a lot about lack (and rot) of management in MS.
Too many managers, but no real decision makers. "Democracy" actually is evil. Each team must have a "boss" ("good boss", rather than "just a boss"). Only good dictatorship can remove delays caused by democracy. Speak with everybody, decide by self - this must be a rule for "good boss".
Personal thoughts about "Sleep or Hibernate". Leave "Sleep" button and do "hibernate" by default, but leave "option" in "Options" for experienced users. (Wow! I've spent 5 seconds to decide!).
As TabletPC user I can say - shutdown menu is crap in Vista! But, believe me, it's not biggest problem in Vista! :D
And some personal thoughts about "complexity and dependency".
Make things simpler! There is no complicated things in entire Universe. Some things seems too complicated? It's just illusion created by humans. Just look closer and you will see just a bricks, nothing more.
Let's take LEGO. Do you need to test LEGO package? Ofcoz, not. Do you need to test EACH (of hundreds) piece? No.
You have:
1. Global design.
2. Common interface to connect bricks (piece) to each other.
3. Pieces specification.
I thing current software companies MUST return to hardware development principles, they are just too relaxed by "we can fix it later via WindowsUpdate".
Simple things needs less attention, less management, less bureaucracy, simpler and faster testing, etc.
MS became too "IBMish" and "Oraclish". They lost power. Additional level of management can't add speed, only just one more level of bureaucracy.
PS: IMHO
I'm probably missing something, but I don't see Microsoft listed at the CMMI web site....... I wonder what kind of software process maturity is in place there.
No wonder you have time to write such a long blog. I hope you are enjoying at Google compared to microsoft. I totally hate it when bureaucracy holds engineers back from delivering good s/w.
I wouldn't be surprised if the final authority in accepting your design was Jim Allchin. I worked for him on Cairo and he was unbelievably annoying with his micromanagment style. From your descriptions, things went downhill from there. My sympathies for you.
The real problem for the Windows world is that no real added quality has arrived since NT4 (which in turn really had only two major things over 3.51, a new UI which was clearly better, and graphics in kernel space which is debatable depending on role). That's very close to zero progress in ten years, folks. Heads should roll at Redmond.
Wow, anonymous, you really nailed it there! Man, I used OS/2 from 2.0 through later versions of Warp and the UI that it shipped with to this day kills anything Microsoft has ever developed. It was a completely different paradigm though, kind of like Next and some of the other more unusual UIs that have come and gone over the years. It takes commitment and effort to go to something completely new like that.
Microsoft isn't "CMM club" member. They have "level 1" only. Find "Immaturity of CMM" article in Google. It explains all.
Interesting.
sounds like you continue to write your self evaluation. I am surprised you didnt break from the mold, rather you alowed your seroundings to dictate your progress. a hundred and something lines of code in a year you produced for the company or should say the "feature". What really was the feature being worked on that year? I am sorry you had the expierence you had.
You do bring out some good insite that will be of use. keep in mind a large company like Microsoft has a long turm projection plan scoped for many things - especialy those things most important. It is because of there size they are alowed to do this. please do not alow your short turm perspective over ride your good nature and CREATIVE productivity.
I do not work at Microsoft or Google.
Apple produces in-house hardware - controls standardisation. This is a major non-trivial difference between Microsoft and Apple. Microsoft endeavours to support multiple different hardware vendors equally.
One of the key challenges in the redesign, inferred by Moishe, was the liaison with the Moltle PC manufacturers each of whome had multiple different hardware-device set-ups for controlling shutdown options. Each of which had slightly different default BIOS settings.
It is unfortunate that what started as a clear vision for a simple UI owned within the team Moishe cites became worn, by multiple different lobbying parties (including Beta-release users - hardly typical users on machine hardware designed for legacy OS's) became simply a different way of revealing the legacy choices.
I currently work at Microsoft was well, it is really amazing that things get done.. ever... I agree with what was said in the blog completely.
OMG
I just discovered your blog. I worked with you on the Microsoft Outlook 97 File System view back in 1996; you represented the Outlook team and I represented Document Management. The memory of the broken development process just came back.
This posting provides good insight.
I'm afraid that the discussed difficulties in organisation, environment and infrastructure are just direct causes of the complexibility of the product.
So, for the number of layers in the team organisation for this product there is no solution probably.
But so many people having an actual -say- in 1 particular area (such as a single feature) is asking for trouble. Every person having a say should limit their say to their own mandate/responsibility/discipline and stay away from unrelated meetings.
Also instead of these scheduled meetings, things might be better arranged ad-hoc. Just walk by, and ask a supervisor (PM?) and maybe a related collegaue from the other team to join if your mandate is limited.
The necessary scheduled meetings might then be better organised around the larger (horizontal and vertical) groups, but in another way.
For example, every month a Windows developer (not feature related) meeting, and also every month a feature specific (not discipline related) meeting. For other disciplines the same could apply, but I'm limiting my post to the development discipline.
These scheduled meetings would be lead by 1 person high in hierarchy for that particular audience, and are meant to share common information, and to provide - or discuss relevant policies. And also to share experiences and to provide (process!) improvement suggestions. On every meeting one person might give a presentation on his recent tasks and his process suggestions.
Bottom line:
1. minimize the current (content related, non-process) scheduled meetings, but discuss this ad-hoc.
2. Share common (process related) information in a well organised, scheduled setting.
jonadab: "take them off to the side, start them from scratch with nothing, and have them implement, from the ground up, the next version of Windows."
I think their work on Singularity, though still a long way off, is just this.
http://www.toomuchblue.com/blog/2006/11/layers.html
ahem, rather than fixing the Shutdown feature, uh... menu I mean, how about fixing the real problem: my circa 2004 computer is more than 5 times as slow as my 1994 computer. In 1994 I pressed the power button and within 30 seconds I could get to work typing a letter, playing a game or whatever. Today I press the power button, go to the bathroom, get a fresh cup of coffee and THEN sit down to work. (150s to login prompt, plus 55s to point of being able to open the start menu). If I was in to computing in 1987 and had a Canon Cat, I could have the computer ready to accept input before my synapses finished warming up (boot time: 7 seconds).
http://en.wikipedia.org/wiki/Canon_Cat
I'm a program manager at another huge IT corporate - would rather not name it for they have policies, these companies, you know.
This CM thing seems to be one of the natural problems of really huge teams co developing something. The code changes are like knowledge and they just can't propagate easily, so this up-then-down merging system becomes common solution.
It's like democracy, it's very bad and not working but I haven't actually seen anything better. If anybody has a solution, patent it and you're going to be very rich very fast.
Alex
Thats a real bad example of code management
I believe Joel or maybe you did mention that Microsoft has grown too big and have become too bureaucratic. Isn't Google headind that way too? At the pace they are hiring it must be chaotic out there...
One of the reasons I still prefer to use my Amiga computers over both the Mac and Windows is that there is no "Shutdown" command at all. You just switch off the power. Ten years ago, I used to teach evening classes, some using Macs and others Amigas. The Shutdown on the Macs added around ten minutes to the time at the end of the class before I could go home. Why is there a Shutdown at all? It suggests to me that there is something wrong elsewhere in the OS which the Shutdown is supposed to fix.
Is that why you have time to blog? :)
if you are a manager, would you like to resign to "save" your company?
Taking programmers aside and writing the "best OS possible" is, of course, the most ludicrous thing suggested here. Microsoft's greatest strength is that it doesn't break compatibility and that compatibility is one thing it cares a lot about.
Also, if you keep chipping away on a particular system making important changes at every release you *will* eventually arrive at an extrememly stable system. NT 5.1 SP3 is certainly a very stable, versatile desktop OS. Considering the multitude of software and hardware it must support.
There is a very good reason why Windows is so much more popular than Mac: the Windows/PC platform is a lot more open. IMO, Windows has arrived at a far better UI than Mac has and that plays a part too. (Of course, we're ignoring Microsoft's OEM monopoly and that a better consumer OS could have appeared in the Win9x days.)
Why are the shell/kernel people involved in it at all? I presume it's just a call to ExitWindowsEx or Hibernate api? But then I haven't seen vista.
In linux, how often would the gnome people keep up to date with everything the linux kernel people do? How often would metacity/gdm keep up to date with everything in kernel/gnome?
It's not unusual for all these teams not to keep up to date with everything that's going on, it's just big. Windows is like gnome+kernel+metacity+all the assorted gnome tools.
But it sounds like there could be various other issues there too.
Seems like it is fashionable to bash Microsoft and praise ....(fill up your blank here).
Moron's who don't have anything of substance to say just need to beat up on Microsoft and look cool :)
close your eyes for a moment and think about your life without Microsoft products and then do the same for xyz, say, google or what ever ...doesn't matter you will get your answer. And yes, that by no means in accidental.
So much noise over nothing.
What Microsoft's staff giveth, the IA staff taketh away.
Problem solved.
I don't know why everyone is bashing Microsoft about Vista. Moishe has made some valid comments, but I don't see why this should mean that "Vista is bad", or "Microsoft makes inferior products". And the sad part is, based on many of these people's commentaries, it's quite obvious they haven't taken the time to get off their asses to even try Vista... it's really sad, seeing that.
That's a very generous description of your UI designer. :) Also, don't forget that you had a User Researcher who did test the myriad designs with real Windows customers in both corporate and home environments. Your post is mostly right on the money and some of the comments are valid, but people definitely underestimate us. They just don't have to deal with the realities since they're designing UI from their Barcalounger.
Despite the strange name, I thought that boolybooly's comment was the most insightful:
"As a result of poor management, the design strategy is clearly not providing a clear lead to programmers and developers.... You can't complete a piece of work if you keep changing the spec.
My diagnosis is that MS bites off more than it can chew, the management philosophy aims for the sky but misses its footing, instead of grandiose revolution MS should be aiming for reliable execution."
And although it sure sounds like the source code management should be revised, no improvement in code quality can make up for a poor spec, impenetrable bureaucracy, or bad user experience design.
I’m surprised everyone is so upset by this article, apparently it’s true what they say about the truth hurting. I’m currently a contractor with Microsoft and coming here from other companies it amazes me how many people they employee to do the same job. I’ve found it a very inefficient way of doing business, and I’ve found it really does take twice as long (if not longer) to accomplish even some of the simplest tasks. There is a large amount of redundancy in people, processes, and in the end, the final product. I work in a totally different group then Vista and have found the exact same issues as described in this article.
When I read this post - and the related follow-up posts, from other MS employees, about the way Microsoft works, I seriously want to apply for a job at Microsoft.
I'm going out on a limb here, but I'm guessing that most of you commenting, like me, generate the main part of your income in the slip-stream of MS related products.
So.. if this is somewhat true, how could it possibly be in your interest to just ignore the problems you all claim Microsoft are suffering? And ranting in this blog is not considered helping in my book.
So I worked on Longhorn and transferred out to Office just after the beta1 release.
There was a lot of time wasted preparing for "reverse integrates" and "forward integrates", but you'd better believe we had automated tests running on that. The trick most people don't understand is that MS has _daily builds_ and _every feature_ needs to be tested on _every_ build, in _every_ branch. That's hard to do, even with labs of thousands upon thousands of computers. It's _necessary_ though, when you've got a layered design as deep as windows.
Oh, and people, MS doesn't use VSS. It's NOT an enterprise-class product. It uses 'source depot', which I guarantee to you is deeper and more capable than anything you've used.
Office is sooooo much nicer though. So little layering that we've only got one branch, a build environment that actually works all the time, and mellow people from Visio to keep the culture relaxed.
http://mcrebbe.com/blog/2006/12/07/microsoft-vista-turn-off/227/
The whole build system comments are very interesting to me, being the creator of CoreXT (I hear it's still around) and quite familiar with the mess.
VBL (Virtual Build Labs) is what is being described in the post. VBL is a system that works around the problem of unstable builds at various branch levels. It's just clever branching in multiple repositories.
The first important thing to note is that VBL is ONLY Windows.
Now, for my 0.02c, the root problem has always been that for one guy (Brian T.) doing the work there's ten managers waiving hands. Moishe, you're a victim of this madness.
Well, CheckPoint has only about 500 developers and guess what - it looks even worse. The meetings could be taped and broadcast as a comedy: You have the guy that talks, the guys that stare having no idea what he's talking about, the guys that snooze and the people with a laptop you just read the papers over the internet. Now, it does not really matter what is decided as once in every few weeks the VP of development drops in and make the decisions. Then she drops in again and alters the decision according to the creator's (Gil Schwed) will. Thank god I cashed out of this madhouse.
I worked on vista too. I read this blog a couple of times, i think if your dependencies were not in place, you should not have started work or spent any cycles on this.
See, there's another new aspect to microsoft: the program manager and the increasing amount of control he has over resources.
She's responsible for the feature: but not for retaining the dev, or developing him or planning for his next review. Thats the dev lead's job, but increasingly she (the lead) has less and less say in what you do.
In other words , does the PM have a lot of motivation for using your time wisely? I don't think so, all he cares about is whether you deliver on the feature she is driving, who cares about the big picture here?
Why it cannot be like in XP? In start-menu you have options "Turn Off Computer..." and "Log Off user". If turn off, then you can choose to shut down, restart or hibernate. Very good. Why there is need to change it? Another idea is that if you want all those options to be there there could be an "advanced" -link somewhere while asking shut down, restart or hibernate.
Hi. I took the liberty of translating your article in French. I find that both the article and your edits show your self-analysis abilities and open-mindedness, and wanted this interesting article to be available to those who suck at english (there are some, in France...). It's here : http://el-padawan.blogspot.com/2007/01/windows-shutdown-crapfest-french.html
I've used trackbacks.
Thanks for your testimony.
I also work at Microsoft, but have only been there for about a year. Nothing that was said in this blog surprises me. I need to show this to my wife, who keeps telling me that the things I complain about are just in my group and not typical of Microsoft. The inefficiencies are incredible. I'm working on Windows Server, which is due to be released later this year. I see some of the problems described in this blog (congested communication), and some that are sort of opposite (lack of communication). I find that we are constantly putting out little fires, and it really becomes a cliche of being unable to see the forest because of the trees.
Not speaking as an MS employee, but as a Windows user, I think Microsoft has been heading in slightly the wrong direction with their client OS since XP. If I wanted a Mac I'd buy one. Please don't give me a Mac OS on my PC. I've used Macs often in the past, and I can't stand them. To me, a Mac OS is something that belongs on a touch screen. What I want is a powerful interface, not a simple one.
I am not a computer guru, I am much more important- A consumer. Vista seems a big waste of money. It is over priced and seems essentially pointless to me- a consumer. What does it do that XP can't? To me it's just another round of endless patches, driver updates and shoddy design. I am already saving up for a mac.
"There is a very good reason why Windows is so much more popular than Mac ... Windows has arrived at a far better UI than Mac has ...
"... as a Windows user .... If I wanted a Mac I'd buy one. Please don't give me a Mac OS on my PC. I've used Macs often in the past, and I can't stand them....."
Oh, I know this is probably a big ask guys, but PLEASE do try and pay attention to the gist of this blog. Let me at least spoon-feed you two points that seem to have eluded you:
1) Moishe's development team used a Mac that was looked upon as a paragon of what a clean UI should look like.
2) If Vista was as good as you two MS apologists claim in your posts and we really did have a better UI than Mac -- and by most accounts it sucks hard -- this blog wouldn't be taking place at this very moment.
Personally, I'm growing weary of being used as a pay-ING beta tester for Microsoft products. I think the best management decision they could make from OUR point of view (if not theirs) is to get rid of an obviously deeply entrenched "ship it, then fix it" policy.
"There is a very good reason why Windows is so much more popular than Mac ... Windows has arrived at a far better UI than Mac has ...
"... as a Windows user .... If I wanted a Mac I'd buy one. Please don't give me a Mac OS on my PC. I've used Macs often in the past [author of this message now trying to lie in an attempt to convince us he's not biased and knows what he's talking about, but failing miserably], and I can't stand them....."
Oh, I know this is probably a big ask guys, but PLEASE do try and pay attention to the gist of this blog. Let me at least spoon-feed you two points that seem to have eluded you:
1) Moishe's development team used a Mac that was "looked upon as a paragon of what a clean UI should look like".
2) If Vista was as good as you two apologists claim in your posts and we really did have a better UI than Mac -- and by most objective accounts it sucks big time -- this blog wouldn't be taking place at this very moment.
Personally, I'm growing weary of being used as a pay-ING beta tester for MS. I think the best management decision they could make from OUR point of view (if certainly not theirs) is to get rid of an obviously deeply entrenched "ship it - then fix it" policy.
close your eyes for a moment and think about your life without Microsoft products and then do the same for xyz, say, google or what ever ...doesn't matter you will get your answer. And yes, that by no means in accidental.
When I do that, I recall a CP/M system that never gave me problems.
Thanks for the memories.
EVERYBODY P.O.'d WITH VISTA WANTING TO BUY A MAC, LISTEN!
i have a couple mac,s a dell with vista and an older gateway with xp. osx is definitely waaaay better that xp or vista. vista is a joke, 5 years of waiting for this? now, instead of telling you all to go buy a mac, 70+% of you people will be very well served with the new ubuntu 6.10 together with automatix2. automatix2 installs all the little codecs and programs that ubuntu is not allowed to distribute. in the end you get a system that now only looks great and and doesnt require a powerhouse to run on, but about 80% of the functionality that makes osx great! all for free, zip, nada.... i had been testing linux about once a year and always came to the conclusion that its not ready for prime time, but now it is.
I've gone from Outlook to Thunderbird and from IE to Firefox in the last year. And now I think I want a Mac. I'm not alone.
Pipelining of a sort was the initial goal of the VBL model. Groups were to start with a common source base, a well defined and working set of common baseline tests and common baseline hardware in the virtual build labs and a well defined set of RI quality benchmarks that would only allow ship quality code to migrate to the main branch.
The respective groups were to do their feature work and produce daily builds for consumption and test within their group. As they got closer to feature complete, the code churn rate was to reduce, the quality of the internal builds were expected to rise to ship quality and then they were expected to raise the "we're ready" flag and RI to the main branch. This would allow for smaller, more flexible teams that could turn and burn code at a much faster rate than what ended up happening at the end of win2k. What was to supposed to happen was shipping quality code coming into the main lab at each and every RI.
The problems that arose that bit this model in the ass: Management did not have any means by which to measure a main build since the first RI might not happen for months. Common baseline tests did not exist (funny how that wasn't brought to anyone's attention until win2k was shipped), no RI quality criteria.
The biggest nightmare was the management nervousness. The other issues we could have and were working to overcome. Given the nervous state of affairs, the plan for the model was largely abandoned and RI's were done on a scheduled frequency basis (usually two weeks) for each VBL. Hardly time to cook new code in the test org and still manage to keep to your feature test plan. Lots of randomization, lots of half baked code being introduced into the main build and then infecting the other VBL's.
Of course broken functionality in one branch leads to all kinds of hell in other branches, and then of course you had fixes for those problems being introduced "cross branch" and that caused all kinds of other headaches (baseless integrations and such, poor/no history of where the code came from or how).
Patience is golden. What eventually became WindowsXP was not.
The reason it came out as good as it did was the long soak time on the main build at the end. At that point all code work on WS03 was halted and ALL resources were to be committed to XP (even teams that had little to no contribution to XP). My team sat essentially idle for the better of 45 days before mgmt. relented and let us get back to work doing something that would let us earn our paychecks. Incredible waste, but with direct injection of code fixes into the main build, things stabilized and eventually shipped.
The Vista debacle has pretty well been outlined already. In essence, we changed course midstream, once again, tossing the baby with the bath water. Incredible waste again. Big plans, big goals, no heart to see it thru to the end, but scared enough to run back to a comfort zone and start over from there.
And the comment about Brian T. is about as true as it gets. There have always been a handful of truly dedicated people who you always go to when you need a job done and done right. Unfortunately, the number of those people are fewer now while the number of hand wavers just seems to continue to grow.
If there was a magic potion that could turn power point decks into real code....
Former softie, ain't never going back...
This article reminds me of my time at Cisco Systems. I didn't feel like there was as much time being wasted as is described in the article, but the source configuration management was certainly an obstacle to getting certain things done, and the many cryptic version numbers of IOS are a symptom of the scary system. On the one hand, you've have marketing people saying that certain features are needed for certain customers in a certain timeframe, and the development team would be able to achieve that easily enough, but on the other hand you'd have the folks who manage the releases saying that there were already too many new features going into that branch. I can't say that I would be able to do a better job in the circumstances, but our branching strategy was so confusing it was likened to the Tokyo subway system (do a Google image search for "tokyo subway map").
It would behoove the powers that be at MS to have read "Birth of a New Machine" and then after digesting the lessons therein, read "Putz Law". For most technical types that have more than one functioning brain cell it explains a LOT about the dysfunctional nature of technical management types and why things end up the way they do.
Sure would have made Windows build an easier pill to digest...
From reading most of this rather long blog, it comes clear that M$ has blurred the levels of software. Remember the Multics "rings". They were rather well defined. You did some stuff in ring 0, you did other stuff in ring 3 (and did nothing in ring 1 or 2 as it ended up).
If there are "multiple dependencies" then the ring's edges have been violated. That will, indeed, cause problems and extreme delays.
Normally, if you want a service from the kernel, request it. It will be added or a previous service expanded without invalidating the features the service provided to previous, established users. Then you add your update to your "ring" and all is well. You don't have to wait on someone else's update unless it is the SAME update you need. Then you are both happy when it comes along but there are no "deadly embrases" that need a dictator to resolve.
As soon as the ring boundaries are breached and groups start waiting on groups instead of waiting on the next ring up, you will grind to a halt.
From what I read, it appears that this separation has been violated and this will cause exactly the problems that are being seen.
Too bad. Anarchy is not a good thing in a mature product(?) or company.
This from 30 years of doing this programming gig and watching how things can devolve into chaos.
Mike Morrow
Someone needs to address the original premise:
"but Schwartz shows the opposite is true, arguing that having all these choices actually goes so far as to erode our psychological well-being.”
Uh, talk about a bathtub load of psychobabble! My psychological well-being is not threatened in ANY WAY by choice. I've also supported many hundreds of clients over the years, and I'm hard pressed to name even one who would face this problem. And believe me, I've worked with some people who weren't exactly the brightest bulbs in the bin.
Joel is on firmer ground when he discusses software that makes intelligent choices for us. The hybrid sleep/hibernate mode for instance. Now that's smart design. It's both fault tolerant and merges two related concepts.
But this has nothing to do with protecting our fragile egos from crushing choices!
The premise of choice has to be that the choice is meaningful to the client. Either that, or the system presenting the choice has an important requirement for making a distinction. And that latter distinction fades over long stretches of time, as the strategic design of the system changes to accomodate user requirements and expectations.
I saw an article at My-PC-Help.com about how to Change Vista's Power Button to Shutdown. Hope this helps!
If a billion of mosquitoes eat shit, are they wrong?
...
Some day will be no more monopoly, more and more people are realizing that there are more options (O/Systems) available. 5 years ago Linux was Greek to me, now I am very happy with it, very, not mention the Firefox which ALL my friends use. It's a matter of time.
all i can say is wow.
beaurocracy is really the devil here. subsistence management is what this has become.
do we not have one of those idiot-savant programmers out there with an IQ of 170 that can just sit down for a month and give us a new friggen operating system that will fix these seemingly really really stupid design issues? why is this so hard? do Ph.D's mean nothing anymore?
i am really dissapointed with most programmers out here when you have people like justin who designed Reaper (www.reaper.fm) with the help of one other guy to fit in a 3 mb installer.
you people who are responsible for this mess and call yourselves programmers should be ashamed...
WOW, I can’t believe that development of Windows Vista was so many mess-ups. Now I am not surprised why Vista did not fill out my expectations. I thing that Microsoft should try to improve team work between their workers I hope that will happened in future or who knows what will happened with next “Windows 7” OS.
Well... i've been a windows user all my life... gone from 95-98-ME-2000-Xp and now Vista... Also went through some server versions too when things started to get nasty, even installed linux for the fun of it.
All is all... Vista ... IS the best by far, from whatever point you look at it. People may be bashing MS a lot... but keeping businesses, home users and developers happy is A HARD TASK and MS is getting damn good at it.
I confess... i even used a mac for a couple of months... you're right ... the UI is better ... can't say about the layers beneath ... i'm not a programmer. BUT... there IS a reason that Mac OS isn't on everyone's desk right now... and that reason is APPLE, they don't want to "scratch" every back in the world, they just do their own thing their own way... and this is not always good.
The users benefited a lot by windows being so widely spread... i'd hate to have 2 people in my office using macs while the other 2 use windows and one of them goes the linux way.
Post a Comment