Horrific blog by an ex Microsoftie on possible reasons for Vista’s slippages. Comments such as An architectural diagram of Windows would suggest there are more than 50 dependency layers (never mind that there also exist circular dependencies) are enough to set any software developer’s hair on fire.
But the silver lining is that if Microsoft by some amazing effort does manage to deliver Vista after the current death march, it is only because they were one wafer short of too much. Which does not make Vista just right like Goldilocks’ third bear; it makes it just wrong. The silver lining is that MS will have reached the end of the road for monolithic systems, and will have to re-architect for the OS after Vista.
But if Vista is so complex that it cannot have a future, why would anyone adopt it? Is that really what all the Windows Live stuff is about, having a good Plan B in place in case Plan A implodes?
The blog also contains a curious bit of logic. The blogger estimate programmer productivity at about 1000 new lines of code per year, compared to 6250 lines average in the US currently, down from 9000 in the recent past. He says So Windows is in bad shape –but only by a constant, not by an order of magnitude. But what if it is an order of magnitude and a constant? If you catch my drift.
Or is this all a terribly clever development strategy to explore the limits of monolithic development: announce an impossible set of features then backpedal until something can be delivered! Embrace that the reality will fall short of the vision. The Jenny Craig school of software engineering, serving only pasta.
First of all, Phillip still works at Microsoft. He's just no longer in the Windows group. Second, go back and read Phillip's post again. While he does address the usual suspects of code complexity and process overhead, he thinks there's really something more to the story. The Armani suit analogy was rather good.
Microsoft can obviously deliver good code: I think MSXML is wonderful software for example. But I honestly don't have any interest in Phillip's thoughts on management and organization: I don't care how Microsoft arranges itself but I do care that Windows moves away from the monolithic direction and spilts into a thin executive for running virtualized OS like some Vista2 and competitor virtual OS.
My suspicion is that what you're seeing here is the denouement of the monolithic era of computing. Bigger, better, stronger, faster can take you only so far, then you reach a place where behaviors become emergent and uncontrollable - in the system, in the development process, in the marketing. You end up building so many layers of abstraction that the OS has to have its own OS just to manage the abstraction layers, let alone the underlying code, and the benefits of building frameworks get lost because the frameworks become far too bloated and interconnected.
Perhaps if their goal had been to improve the XP line rather than replace it altogether, they may have saved themselves an incredible amount of grief, but that point has long since passed.
Finally, I agree with your assessment on Windows Live - Plan B is called the Internet, and in the end, it may be all that saves MS from complete ruin.
Two things,
Since when did lines of code have anything to do with productivity? I would argue that the fewer lines of code to get the job done is WAY MORE PRODUCTIVE than less.
Second... The US average is 6250 lines of code???!!! I wrote that much code last week alone!!! ;) :D (although with the above argument it doesn't really lend well to this representing all that much productivity, huh?! hmmmm.... )
e.g. http://www.xsltblog.com/archives/2005/11/its_people_like.html
One last question: How are they counting their lines of code? Is it lines of code that make it into a production release? Total lines of code, no matter if its foo bar test code or production code?
The reason this seems like such an important question is that from my own experience, when you sit down and start writing code for a project theres a tendency to get out all of the ideas and such out and into a hacked together, pseudo-code-ish framework, to then spend the time necessary to refactor, optimize, etc... So while the end result may only be a 1000 lines of production code, it may have taken me 10,000 lines of "thought process, refactoring, and optimization" code to get there.
To me, studies that suggest lines of code as a point of productivity have no clue that quality of software, and the process of writing this software have NOTHING to do with the lines of code written, and EVERYTHING to do with how efficient and productive the final code base is in regards to performing its intended function.
It is true that metrics like lines of code or comments per line of code or fanout or cyclomatic complexity or percentage of functions with greater than some metric don't tell you much. But they do tell you something. The trick is to figure out what they are saying. In the fact-overburdened but overview-scarse world of software development, any kind of summary information is useful.
Horrific blog by an ex Microsoftie on possible reasons for Vista’s slippages. Comments such as An architectural diagram of Windows would suggest there are more than 50 dependency layers (never mind that there also exist circular dependencies) are enough to set any software developer’s hair on fire.
I do not agree. Go to http://www.hotelshomes.info/jihad_France/snip_Ile%20de%20France/amphibia_Paris_1.html