A little taste of how Vista was made...


G

glsj.dw

WARNING .. this story might shatter your brilliant image you have of
microsoft and vista.

http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html

The Windows Shutdown crapfest
I worked at Microsoft for about 7 years total, from 1994 to 1998, and from
2002 to 2006.

The most frustrating year of those seven was the year I spent working on
Windows Vista, which was called Longhorn at the time. I spent a full year
working on a feature which should've been designed, implemented and tested
in a week. 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:



a.. 1 program manager

a.. 1 developer

a.. 1 developer lead

a.. 2 testers

a.. 1 test lead

a.. 1 UI designer

a.. 1 user experience expert

a.. --

a.. 8 people total

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
 
Ad

Advertisements

D

DX

* Yawn*

glsj.dw said:
WARNING .. this story might shatter your brilliant image you have of
microsoft and vista.

http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html

The Windows Shutdown crapfest
I worked at Microsoft for about 7 years total, from 1994 to 1998, and from
2002 to 2006.

The most frustrating year of those seven was the year I spent working on
Windows Vista, which was called Longhorn at the time. I spent a full year
working on a feature which should've been designed, implemented and tested
in a week. 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:



a.. 1 program manager

a.. 1 developer

a.. 1 developer lead

a.. 2 testers

a.. 1 test lead

a.. 1 UI designer

a.. 1 user experience expert

a.. --

a.. 8 people total

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
 
P

Peter Lawton

Nice to have a post in this group that I actually read all of and found
interesting

Well done

Peter Lawton
 
C

Charlie Tame

Actually that sounds fairly typical of many activities "Big" companies
engage in, and it almost always comes out the lowest common denominator.

I set up a system once that was designed with security in mind, and to
check my own work implemented an very complete logging / history of all
transactions.

I was constantly asked to dumb it down and constantly discovered
attempts by managers to cheat the system for their own benefit. When
this went to the higher levels of management I was the one got fired :)



glsj.dw said:
WARNING .. this story might shatter your brilliant image you have of
microsoft and vista.

http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html

The Windows Shutdown crapfest
I worked at Microsoft for about 7 years total, from 1994 to 1998, and from
2002 to 2006.

The most frustrating year of those seven was the year I spent working on
Windows Vista, which was called Longhorn at the time. I spent a full year
working on a feature which should've been designed, implemented and tested
in a week. 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:



a.. 1 program manager

a.. 1 developer

a.. 1 developer lead

a.. 2 testers

a.. 1 test lead

a.. 1 UI designer

a.. 1 user experience expert

a.. --

a.. 8 people total

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
 
M

MICHAEL

Charlie,

Did you send that email, yet?


-Michael

* Charlie Tame:
Actually that sounds fairly typical of many activities "Big" companies
engage in, and it almost always comes out the lowest common denominator.

I set up a system once that was designed with security in mind, and to
check my own work implemented an very complete logging / history of all
transactions.

I was constantly asked to dumb it down and constantly discovered
attempts by managers to cheat the system for their own benefit. When
this went to the higher levels of management I was the one got fired :)



glsj.dw said:
WARNING .. this story might shatter your brilliant image you have of
microsoft and vista.

http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html

The Windows Shutdown crapfest
I worked at Microsoft for about 7 years total, from 1994 to 1998, and from
2002 to 2006.

The most frustrating year of those seven was the year I spent working on
Windows Vista, which was called Longhorn at the time. I spent a full year
working on a feature which should've been designed, implemented and tested
in a week. 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:



a.. 1 program manager

a.. 1 developer

a.. 1 developer lead

a.. 2 testers

a.. 1 test lead

a.. 1 UI designer

a.. 1 user experience expert

a.. --

a.. 8 people total

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
 
F

Frank

glsj.dw wrote:



----lying bs article posted by capin' crunch deleted---

Give it up bozo. Nobody cares about a wannabe journalist like you.
Frank
 
Ad

Advertisements

A

Alias

Frank said:
I gave it up when I realized I am a bozo. Nobody cares about a
wannabe journalist like me.
Frank

Congratulations, Frank. Admitting you have a problem is the first step.
 
C

Charlie Tame

MICHAEL said:
Charlie,

Did you send that email, yet?


-Michael

Not yet, nothing really important but will do later.

That company in my reply BTW was essentially cheating the tax man - bad
idea at the best of times but even worse when you are stupid enough to
do what they were doing - and a month or so after I "Left" got hit by a
major inquiry by the tax folks :)

Fortunately I had already explained the situation to the corporate
accountant who had taken the trouble to monitor who was trying to do
what - so he was able to keep himself and the corp out of it - it
certainly was not common corp practice - so in the end the right people
got nailed.
 
Ad

Advertisements

J

Jupiter Jones [MVP]

Changing his words and meaning, and you call other people a liar?
That makes you WORSE since by doing so, you make it more difficult to
see what is actually said.
Another new low for you Alias.
Extremely despicable of you to need to change someone's words just to
suit whatever twisted purpose you may have.
You are becoming worse than a liar if you continue this path.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top