Slashdot Mirror


Why Vista Release Date Really Slipped

anzev writes "A team manager for Windows for 5 years has decided to write a blog-essay about what caused Windows Vista project to miss the due date. Philip tells us in the blog, that Windows developers are writing an average of 5000 lines of code (which is *only* 1200 lines less than the national average of 6200 lines of code per year). He addresses issues like the Vista code being too complicated, the processes the developers have to follow too complex and a lot more. All in all it gives a nice insight into why Vista will be late, from a different perspective. Oh, and Slashdot gets mentioned too ;-)."

10 of 562 comments (clear)

  1. SLOC: Vista vs. Linux by (1+-sqrt(5))*(2**-1) · · Score: 4, Interesting
    From TFA:
    We shouldn't forget despite all this that Windows Vista remains the largest concerted software project in human history.
    David Wheeler, for instance, calculated that Redhat 7.1 contained 30,152,114 physical source lines of code (SLOC), a 60% increase over 6.2 (and that was in 2001).

    Linear extrapolation would take us to about eighty-two-million today, comfortably over Vista's projected fifty-million; but who's counting?

    1. Re:SLOC: Vista vs. Linux by Zigurd · · Score: 5, Interesting

      Now, if the Debian project managers were told to write specs for all n-thousand of these modules, and then told "deliver these modules so we can have the next 'eager beaver' release," then you'd be looking at a concerted effort.

      You have answered youself: TFA asks if a project the size of Windows in controllable. In an environment where the tone is set by Steve Ballmer the answer sure looks like "No." Maybe "Hell no."

      TFA also states Windows has 50 layers and circular dependencies. Linux has complex version and interface dependencies, too. But, evidently, the Windows dependencies are hairy enough to flummox 2000 smart people working in "concert" while Linux gets by with only a handful or people working in the same place at the same time and a much simpler process.

      That is, Linux has better modularity and less process.

      That points to the depth of the problem at Microsoft: They will have to change almost everything about how Windows is made in order to get a different result:

      They have to stop telling developers to "do or die." Has that ever happened in the entire course of Linux development? Probably not. It's something that software project management can do without.

      They have to get strong product management that knows which features are actually important, so you don't get that "do or die" message being sent to teams that are making things that don't add that much value.

      They have to decouple development more: Why on Earth do you need to have 2000 people working in concert on any software project? That's a bug, not a feature.

      They have to un-layer their management structure. 11 layers? That's ridiculous for a software company.

      There is no one prescription for success. Apple succeeds by having very strong product management, so they know which features are actually important to the end user. Linux succeeds by having no product management at all, and having to adapt process to the practical constraints of being FOSS. Microsoft is stuck in the middle: Not enough product management strength to know which parts really deserve a "do or die" effort, and so much process, interdependency, and management layers that any of the 500 product managers Microsoft already employs that are smart enough to make these decisions can't possibly put them into effect.

  2. Source for averages? by Anonymous+Brave+Guy · · Score: 4, Interesting

    I thought the number of finished lines of code per developer-day (that means debugged, documented, etc.) was only 20 for an average developer? A top developer will get closer to 10x that (mainly because when they write a lot of code in a day, they don't introduce lots of silly bugs that take a lot of time to correct later). Some developers actually have negative productivity overall (which makes sense when you consider the time spent by their colleagues to fix their bugs afterwards).

    I can't remember where I saw those stats: probably something like Code Complete or The Mythical Man Month, I imagine, or possibly the IBM study into developer productivity at different ages (the one that says anyone under 25 is only good for documentation, and anyone 25-30 should only work on one project at once). Does anyone recognise the number?

    I can't see any references in the blog post. Where do the figures of 6,200 (and the earlier 9,000) LOC/year come from?

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  3. it's kind of obvious what's wrong by thechronic · · Score: 5, Interesting

    The guy is saying there are 50 layer dependencies, and tons of circular dependencies. It's software engineering 101, their model is wrong...they're not properly abstracting out each layer. I'm not a big fan of Linux, but every module can be decoupled in it, and modules work together even though they're written by completely different projects due to standards...that's how you design a proper system.

  4. Ballmer used to complain about this! by Cybrex · · Score: 4, Interesting

    In the documentary miniseries "Triumph of the Nerds", there's an interview with Steve Ballmer where he describes the various factors that led to the fallout between Microsoft and IBM. One of the big things that he harps on is how the IBM programmers were too focused on KLOCs, while the M$ guys were striving for streamlined, efficient code.

    Now we've got one of the head guys on the Vista project going on about KLOCs. Is anyone surprised? Me neither.

    --
    Boundless Expansion, Self-Transformation, Dynamic Optimism, Intelligent Technology, Spontaneous Order- BEST DO IT SO!
  5. You have to appreciate the transparancy of MS by Momoru · · Score: 4, Interesting

    It amazes me how transparent Microsoft lets itself be. The fact that someone can even post a blog like this about the company using internal company resources. As much as we rant about Microsoft being evil, you'd never see anything like this from Google, the only blogger about the internal day to day Google I know of was fired (Mark Jen).

  6. Re:Yeah, whatever. by jc42 · · Score: 5, Interesting

    If MS has the guts to burn 10 Billion - 20 Billion on getting a new OS paradigm on to every plattform on the planet and do a good job at the same time they'll maybe make it.

    It's perhaps worth mentioning that this was essentially IBM's approach back in the early days of "desktop" computers around 1980. There was this flock of little upstarts challenging IBM's growing stranglehold on the computer business by building small, cheap computers. IBM actually had a desktop computer, and it got very good reviews from its users. (What was it's 4-digit number? I've forgotten, but it was pretty good. ;-) Their problem was that, due to their development rules, they couldn't sell it for less than $50,000 and recover their development costs. And they couldn't sell more than a handful at that price.

    So they farmed the job out to one of those startups, run by Bill Gates and a few of his buddies, handed them a few hundred million for marketing, and didn't impose the IBM development rules on them. The result was crap compared to any of the CP/M desktops, but with a marketing budget greater than the operating budgets of all the upstarts combined, the result was what IBM wanted.

    Microsoft has understood the lesson of this from the start, and put their money into marketing rather than quality product. Until now, maybe. If the reports of their growing development rules and costs are true, they may be going the way of IBM. They'll produce a good system for the first time in their history, but to avoid going bankrupt from the cost, they'll have to get a very good price for it, and only the wealthiest (and stupidest) will pay that price. If this is true, we're seeing a repeat of the IBM/Microsoft story from a quarter century ago.

    Of course, IBM didn't die. In fact, they completed their conquest of the "mainframe" market, which was willing to buy IBM no matter what the cost. They completely own that field, and development has pretty much come to a halt. Due to MS's market clout, we could see the same outcome. They will own the "desktop", and further development in that market will grind to a halt. They'll still sell to the "MS at any cost" market. But it won't matter to most of us, because we'll more and more consider "desktop" computers relics of a previous age. We'll stop worrying about making new systems "compatible with the desktop" (i.e., clones of MS's systems), just as 25 years ago we stopped worrying about whether our little computers were IBM compatible (and we didn't bother with PL/I or JCL ;-).

    So what should we call the new thing we're building while ignoring IBM and Microsoft? "Web 2.0" seems to be out (and wasn't very good anyway), but the new thing will certainly be Net-based. Any good suggestions for a name that will supercede "desktop"? Maybe we need a catchy two-syllable name for the software going into the OLPC project. Push for making it a truly distributed, comm-based system without any central control, so the comm companies and local governments can't take it over as they're doing with the Web. We can base it on zillions of small components, so a company that refuses to follow standards can't make any inroads. The "new paradigm" will be as outside Microsoft's world view as PC/DOS was outside IBM's world view.

    C'mon, we need a catchy new name ...

    --
    Those who do study history are doomed to stand helplessly by while everyone else repeats it.
  7. Re:Summary == Wrong by korbin_dallas · · Score: 4, Interesting

    Cowboy!

    In a 'REAL' company, you have to do:
    1. Requirements
    2. Requirements Review (meeting)
    3. Complete Requirements Review paperwork,and store that

    1. Design
    2. Design Review (meeting)
    3. Complete Design Review paperwork, and store that
    4. Complete a Design Checklist,and store that

    1. Then you get to Code. (insert 1000 lines of code here)
    2. Have a Code Review (meeting)
    what this really means is that you need to tie up 2 other developers to check your 1000s of lines)
    3. Revise all changes and complete Code.
    4. Complete a Code Checklist and store that

    1. Unit Test

    1. Integration Test

    1. Update and maintain the Software Design Document (ongoing).

    Welcome to CMM!

    For us the metrics are about 30 lines per day, but for Rule of Thumb we use 18.

    The project I am on started as R&D,then it was fun, we just coded like you did. We did ALOT of good stuff. Then when the product sells and makes ALOT of $$$$, we started to get all these MANAGERS, the ones who thought we were all STUPID, piling onto the project SUKING up all our money. Then we get this CMM crap to do too. Some of it helps, At least if my Requirements change, I start at #1 and managment, if they have any questions, see what the impact of thier whims are.

    Now if somoeone would just buy Serena and put PVCS out of its fscking misery. Oh Happy, Happy, Joy, Joy.

    --
    They Live, We Sleep
  8. Re:Give Vista Developers A Break by Spiked_Three · · Score: 5, Interesting

    LOL - I got a huge kick one time at a Microsoft SE meeting where some dumb SE gave Gates grief over Microsoft's implementation of DCE RPC. Gates ripped him a new butthole stating intricate details of DCE specs and it's failing points and how code was written to get around the problems.

    There does not exist in all of slashdotdome more of a nerd than Bill Gates (nor anyone as rich).

    --
    slashdot troll = you make a compelling argument I do not like the implications of.
  9. Simple Lessons by radtea · · Score: 4, Interesting

    The article describes the basic things that are wrong with virtually every late project:
    • Managers who can't handle the truth
    • Developers or lower level managers who lie to fulfill the psychological needs of managers who can't handle the truth
    • A marketing-driven schedule culture that declares "drop dead dates", misses them, and nobody dies
    • Input rather than output focused management (action control vs results control)
    • Managers who interfere inappropriately with technical decision-making
    • Excessive project mangement/process burden--the level of process needs to be just right for a project to run effectively, and needs to retuned on a per-project basis by people to whom success is more important than ego


    He is describing a sick management culture, one peopled by individuals who are not part of a reality-based community and not aware of their own deficits. Projects run by people like this will always be late and frequently fail completely, because reality doesn't care about management egos.

    This is pretty typical of modern management culture. It just shows up more clearly in this case because of the length and size of the project.
    --
    Blasphemy is a human right. Blasphemophobia kills.