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 ;-)."
Linear extrapolation would take us to about eighty-two-million today, comfortably over Vista's projected fifty-million; but who's counting?
This isn't some critical release patch.
This isn't some driver that's long overdue.
Microsoft never hand signed a sheet of paper telling me that I would have my copy of "Longhorn" by the end of 2005 or even 2006.
It's a new operating system. More importantly, it's an operating system that has to compete with OSX, Linux, Unix & Windows XP. That's right, they are going to have to figure out someway to improve Windows XP. They aren't stuffing Madden 2005 into Madden 2006 and I hope they are taking their sweet ass time to rework some of the Windows internals that may have been a long time plague on the OS.
My point is that they're making something new and probably forging new ground. According to this article, they suffered the same thing a lot of projects have suffered. You project management plan looks great in Microsoft Project. Then you print it out and re-wallpaper the offices only to have the developers sift through it and go, "What the fsck?"
If Vista is as complicated as its specs say it is, I hope Microsoft takes another two years to get this done because I don't want to have to put up with Vista SP1, Vista SP2, Vista SP3, etc. down the line. I think games like WoW took a lot of time to make but it paid off to be a really stable engine with great features that blew everyone away. Microsoft could learn from that. You might upset some fans and you might piss your boss off but misinformation/miscommunication in the early stages of a project only lead to its downfall. If you can voice concern/dissent to your boss, I suggest you get a new job. We're human beings, we are fallible and we do have limits. Even if we're hand selected by Microsoft's HR department.
I'm reminded of a story about Hitler where the Allies had broken through French beaches at Normandy (unexpectedly) and Hitler's aides were at his house trying to figure out how they could wake Hitler up and inform him of the brigade of tanks rushing across the countryside towards them. Because they all feared for their lives, no one ended up waking him up and they lost a whole lot of ground & a few resources because of it. If you run your company through fear and people can't talk back to you, you'll end up like Hitler. Dead in a ditch with petrol all over you.
I'm also getting really sick and tired of people measuring a project's greatness by KLOC. It's also very frustrating to hear people brag about how many KLOC they write each year. That's great--now how do I know it's not riddled with bugs or a complete memory hog? What ever happened to the desire for elegant computer code? When I see a program that does something quickly and elegantly, my brain releases the same chemical that I used to get when I saw beautiful math proofs. I know this is the mark of the nerd but there's something very satisfying about it.
One last note, this MSDN blogging site does not care for Firefox. The right hand side of the text hangs over about an inch into the right bar side and it's annoying because the text spills onto the calendar. I certainly hope this doesn't happen on purpose.
My work here is dung.
Obviously the other thing that is too complex is the whole to/too/two thing ;)
Blessed are the 1337, for they shall pwn the earth.
Wow, who uses lines of code as a metric. It's an aweful metric to use. I have seen many bad coders produce a lot of code. Lines of code as a metric encourages cut and paste reuse instead of abstraction of common ideas and functions.
As x approaches total apathy I couldn't care less.
The largest software project in mankind's history now threatens to also be the longest.
Nah, that would be Duke Nukem Forever........
How in the world did Vista ever become the "largest software project in mankind's history"? I mean, this is an operating system. This is just an OS for a microcomputer, for pity's sake! It's not running the Internation Space Station. It's not running a nuclear aircraft carrier. It's just supposed to manage a personal computer.
This shouldn't be so hard. It shouldn't be so big, or so complicated. I know we expect our computers to do a lot these days, but still. . . Shouldn't application software do most of the heavy lifting anyhow? I'm just trying to figure out why it takes hundreds of megabytes of OS -- and fifty levels of dependencies, according to the article -- to manage a desktop computer and provide APIs.
It's not just black & white, it's black, white and atleast seven shades of brown.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
He said:
The types of software management issues being dealt with by Windows leaders are hard problems, problems that no other company has solved successfully.
Nobody else has solved the problems? How is it that OSX, which contains many of the features that Vista is due to have, shipped years ago? Before the Microsoft fanboys start with "Ah but it's different...", I think Microsoft is guilty of making their own problems... Perhaps some problems shouldn't be solved in software, but should be solved at the level of how your company works.
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.
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.
People are always concerned about writing out gobs and gobs of code that isn't properly thought out. That's the problem with a lot of software development these days (namely OSS). I've been digging through a rather large and prominent OSS project and found that its code looks like it's been hacked together.
People need to start focusing on code density. By code density, I mean how much thought goes into each line you write. High code density will almost always give you a good result, take Google for example, I've found that almost everything they have has been well thought-out, and not hacked together in a rush.
If MS has told the developers to slow down and think through everything, I think everyone (who will use Visa) will benefit in the end. I'd rather have a late OS that works than one that is early and feels rushed. Now before I get flamed and labelled as a Windows fanboy, I should mention that I use OSX as my native desktop OS and Linux (Gentoo) for my personal servers.
... who think this writer should lay of the Ctrl+B for a bit? The emphasis in my inner voice is driving me bonkers.
Yes, lines of code is a crap metric, but let's face it--the "manufacturing frozen hamburgers in a box"-school MBAs don't understand software development, and never will. I work for a subsidiary of Really Big Company (no, that's not implying their company name is RBC, or has those letters as the first part of any of their name bits), and Really Big Company mostly supplies a particular kind of hardware to the world of commerce. Our new company president has a degree in engineering, and historically he's been a hardware sort of guy.
(He's not a bad person. Honestly. He's under the same gun as the rest of us, and working hard to make sure we meet our targets. I'm not doing character assassination here--at least not directed toward specific individuals.)
The folks at Really Big Company give us revenue targets every year. If we miss those targets, the next year the targets are higher, no matter the state of the economy, the solvency of customers in our particular market niche, or our saturation level in that market niche. To me it makes no sense, but I'm not an MBA. (Clearly the management team at Really Big Company doesn't consist of too many dog owners. It's patently obvious that if a dachshund can't jump through a hoop two feet off the ground, it won't be able to jump through a hoop three feet off the ground. Perhaps they're avoiding that concept to skirt patent infringement issues.)
(Personal aside: my older cousin, a mechanical engineer by training, got an MBA last year. I consider him a traitor to the cause, and am no longer speaking with him. He doesn't know it, and I can't tell him, because I'm not speaking with him.)
The problem with hardware people, and it doesn't matter whether the hardware is computers, lawn mowers, or frozen hamburgers in a box, is that they deal in tangibles. At the end of the quarter, either one has 1,000 model 59-C units in the warehouse for delivery, or one doesn't. At any time during the quarter, one can count the number of computer model 59-C units and see whether or not the schedule will be met. One can determine whether or not vendors are supplying the parts required to build 1,000 model 59-C units at a rate commensurate with meeting the EOQ deadline.
The problem is, software is entirely intangible. We don't have vendor issues--if we have a compiler, an editor, and a computer on which to work, we're good. As far as the MBAs know, we're spinning moonbeams and weaving webs of purest electricity. While the reality is not quite that prosaic, it's not far from the truth. Everything I have ever done in my programming career (even that game I marketed 15 years ago, the source code for which is still on my latest computer at home) exists purely as an abstraction, nothing more than specifically-configured magnetic signatures.
What we know at the outset of the software project is that we want a Program That Works. What we don't know is how long that's going to take, and it's hard to estimate how long writing a new file system, security layer, or UI component might be, even if we've done it before in another context. The difference between building model 59-C units and writing software is that halfway through the manufacturing cycle no one comes to tell you that the model 59-C unit has been partially redesigned, and that it now uses a stainless steel internal frame instead of cast aluminum. (In the world of tangibles manufacture, the stainless steel version would have a new model number. This doesn't happen with software. The requirements change, and we keep calling it the same old thing.) Specific case, referencing Vista: suddenly WinFS is not part of the shipping configuration, so all the code in other parts of Vista that assumed WinFS would be present have to be rewritten, and then retested both at the unit and integration level. This stuff takes time. It can't be done on the original schedule.
The
what I've seen on other very large projects. So much time is consumed with unit testing, making sure you don't introduce side effects, and studying existing code that the creation of new code slows to a crawl.
I worked on a project that had ~ 8 million lines of code. Code quality dropped so far we had to institute a weekly review - no one was allowed to commit a change until it had been reviewed by the entire team. It always pissed us all off to have to do it - but it turned out to be hugely effective at improving code quality, training new engineers in all the little details that never get written down, cross-training experienced engineers in portions of the code they hadn't worked on and, as a bonus, teaching us all how to write defensively and think about all the likely side effects of our changes.
Clear, Dark Skies
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!
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).
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.
;-) 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.
;-).
...
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.
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.
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
The article describes the basic things that are wrong with virtually every late project:
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.
"We achieve great results from ordinary people with a brilliant process. Our competitors achieve mediocre results from brilliant people with a mediocre process. They try to overcome this by hiring even more brilliant people. We are going to win."
From [name of online dictionary service]
[word in question]
1 : [widely-used definition everyone is familiar with]
2 : [something else]
If we take the second meaning, then yes, [original argument] IS in fact [statement of truthiness]. It's the [supporting justification] and [further reinforcement] which defines them as [paraphrase of second definition].
[mildly humorous non-sequitur analogy]
[suggestion to RTFM]
[obligatory Wikipedia link]