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 ;-)."
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.
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.
Debian isn't a concerted effort by any stretch of the imagination. It consists of thousands of modules that really exist independently of one another; the vast majority of them were not even written specifically for Debian at all, but rather for Linux in the general sense. They were simply included in the package. I'd go so far as to guess that some of them made it in "by proximity" -- they were in the same directory as something useful, and someone came along and did a 'cp coolutility/* /distro/coolutility/*'.
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.
John
Yeah, so? You have no idea if that 5000 lines of code is faster, more efficent and easier to modify than that 6200 lines of code. Don't you remember the Apple story? Stupid ignorant nubs.
Slashdot: Playing Favorites Since 1997
Workers blame the managers
The way this blog is written makes it obvious why its late, and why it probably won't hit the needs of the users. All the effort goes into playing the bureaucracy game and between the 'them' and 'us' everything important gets lost.
Personally I believe its a failing of the MBA courses, etc. The idea that 'A' controls 'B', rather than they work together as a team is prevalent and its fundamentally incompatible with good projects. By default I tend to look questioningly at those who claim to be able to manage because 'they've done the course'. Too often they forget they are costs to the programme and have to offer real, obvious, value to be worth having.
We need project management, version 2.01
It also depends on how you draw the line on what's a single software product.
Vista Ultimate is going to have tons more code than Vista Basic simply because of all the extra bundled apps. Linux is another good example--Red Hat includes the GNU tools and assorted applications, Ubuntu's base distro fits on a single CD, whereas Debian and SUSE's official distros provide everything but the kitchen sink and probably contain an order of magnitude more code as a result.
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.
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.
Other than people who get stuck with Vista on a new PC purchase, who is going to buy copies of this? I can't imagine another painful cycle of OS upgrading just to get what I feel is essentially eye candy that likely won't even work on the 12-18 month old hardware at our office.
It will be interesting to see how successful Microsoft is in pitching this "upgrade" to enterprise customers with thousands or tens of thousands of seats.
From TFA:
Lest those of you who wrote 5,000 lines of code last weekend pass a kidney stone at the thought of Windows developers writing only a thousand lines of code a year, realize that the average software developer in the US only produces around (brace yourself) 6200 lines a year. So Windows is in bad shape - but only by a constant, not by an order of magnitude.
So - windows programmers write 1/6th of the code that other programmers do, and they wonder why they're behind? D'oh!
Also from TFA:
Vista is said to have over 50 million lines of code, whereas XP was said to have around 40 million.
It's a frigging operatiing system, for god's sake. Just for comparison purposes, does anybody have any (reasonable) numbers for LOC in both Linux and X Windows? Mac OS/X? I'm guessing there there's just a wee bit of bloat in there.
And worst of all, there's the 50 dependency levels that were mentioned. WTF are they doing - writing the bloody thing in GWBASIC, line numbers and everything?
Noone was using SLOC for quality - they were using SLOC for size.
Great merciful Zeus! I have done 6200 lines of NEW CODE in a DAY.
You may rise (zabalflabin)
Lines of code is a stupid metric. It's on the wrong side of the balance sheet. Lines of code is a cost, not a benefit. As a software engineer, your job is to express concepts in as little code as possible. That's why we have high level languages like Lisp, Haskell and Ruby.
On the other hand, we have people who try to fatten their lines-of-code metric, which is why we have assembler, C, and TheDailyWtf.
If anyone asks me for how many lines of code I've written in a day, I will either respond with a negative number, which is probably correct, or if I'm feeling vicious, One.
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.
From Merriam-Webster Online Dictionary
Concerted:
1 : to settle or adjust by conferring and reaching an agreement
2 : to make a plan for intransitive senses : to act in harmony or conjunction
If we take the second meaning then, yes, free and open source developers are in fact acting in harmony or conjunction. It's the software license and underlying philosophy which defines them as acting in concert.
Just because a flock of birds doesn't have a leader giving orders doesn't mean they aren't acting in concert.
Read up on self organisation and emergent systems:
http://en.wikipedia.org/wiki/Self-organization
Deleted
The larger the project that you are adding code to, the more you have to think before acting. 1000 lines of code added to a 50 million line code base can be much harder and more time consuming than writing a 10,000 line application.
Software really is tough. Large software is much tougher. As the "largest concerted project" ever, Windows Vista is pushing the limits of human capabilitity for coordination and communication. Each new module, and its attendant interfaces, adds new communication.
As communication increases, total overhead increases. In some cases, it increases in a combinatorial way. If we estimate the "efficiency" of a component as the value-it-brings (in terms of work saved elsewhere in the code) divided by the ( development-time + communication-overhead ), you always want this efficiency to be well over 1.
Is it less than 1 already? If so, can you really ever complete a project this way?
Linux distributions (including this linearly extrapolated Red Hat Linux) contain an office suite, development tools, and a DBMS, so you should also compare them to Office, Visual Studio, and SQL Server.
Since when is the size of a project and needed resources expressed in lines of code?
Consider a 5 person project with one manager. They're building an "innovating revolutionary" program.
Bob came up with the same idea, but codes in his free time... However Bob is less organized in his coding, and still is "learning" so his code will be less efficient.
The team releases their version, as does Bob.
Bobs program counts more lines then the teams' but the team put more resources into managing the project and communicating back and forth between 6 people which takes alot of organisation, meetings, brainstorms and some sort of coding-standards/protocols to be able to work together on the same code when Bob just turned on his PC whenever and just coded away.
Now which project is 'bigger'?
Bob's project? or the teams'?
Bob has written much more code but the team put alot more time and resources in theirs.
I think we can keep recursing like this until someone returns 1
You're looking at it from slightly the wrong direction.
From what I remember, lines of code per unit of time are language invariant. That is, an assembly language programmer will write the same number of debugged lines of code per day as a C programmer and as a Lisp programmer.
Thus, the drive to higher level languages is that you can do more with each line of code.
The downside is something you didn't directly mention - the need to master large libraries of code. Most of the examples in the Daily WTF are caused by people who didn't realize there was a library routine to do what they wanted, or didn't understand the features of the language they were using - not because they were trying to pump up the amount of code they produced.
Clear, Dark Skies
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
The desire to be all things to all people. Desktop, handhelp, servers, games stations etc. It just muddles things up. It is a architecture driven by marketing. And I wish I could find the video, but some months back I saw a video interview with the Vista team leads and several red flags went up including:
1) A huge code base which included code no one understood.
2) OS design by marketing. They would have to accommodate design changes from the IE team or the Office team.
3) A large team size.
4) Large backward compatibility issues.
It had all the markers of a disorganized project that was drifitng.
It also does not help that it has to operate on a witches brew of cheap commodity hardware. The incompatibility work arounds have got to be a head ache.
If you look at the propreitary Unix model, Solaris, AIX, OSX etc., you have a hardware manufacturer with an OS which, at least theoretically, be designed and tuned to play nice with the hardware. This is why you pay the big bucks, theoretically, reliability and performance.
Microsoft, to a certain degree, is not the master of its own destiny as long as it has to depend on outside hardware makers.
And, in fact, I think Linux and some *BSDs have the same problem. Too many hardware configs sometimes leading to interoperabilty issues (though with open source you can do things like recompile the kernal or your own drivers). Which is why I switched to OS X, I got tired of hunting down drivers and libraries; and doing recomplies.
putting the 'B' in LGBTQ+
I miss the days when people took pride in using less code and/or more efficient code to do a given task. Now writing *more* code to do a task is in vogue?
SLOC is only a good measure of SLOC. A "project's size" can be very large in scope, requiring a lot of research and a lot of very smart people working for a long time -- and the end result may be a few thousand lines of code that is extremely well written/optimized.
Granted, SLOC is probably "somewhat indicitive" of a project's size 80% of the time. But can you make generalities about such an exceptional (and not just in a good way...) piece of software as Windows?
Yeah, that's my reaction, too. 5,000 lines of code per day? That doesn't sound like responsible software engineering. It sounds like a code binge - and let's face it, we all know how that generally turns out.
If Microsoft were really committed to quality code, it wouldn't project a release date for Vista. It would announce a release date when the code was approaching completion - perhaps even the first few public betas. By projecting a release date before then, Microsoft limits its options for responding to deep bugs that arise during the beta: its solutions have to be shoehorned into fitting the projection. That's what it sounds like it's doing.
I've been an ardent Microsoft user since 3.0 - no, since the early days of running MS-DOS on a 12MHz 80286 - but Vista is the first Microsoft OS that I really don't want. The features that Vista offers over XP don't justify the added complexities and new security holes of the new platform (not to mention the planned hardware and software obsolescence.) And all of this "creeping oversight" BS - Hailstorm, DRM, Palladium, Windows Genuine Advantage - makes me leery as well.
Microsoft has always been hostile and unfair to its competitors... but now it's being hostile and unfair to its users. I'm not inclined to tolerate it.
- David Stein
Computer over. Virus = very yes.
use perl use CPAN, then everything is done in "10 lines of perl".
yes, i'm a lazy bastard.
"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."
...and then he tells us that the truth in fact is just that...
I'm sorry but for me it just seems like a bunch of poor excuses.
...and yes, Vista is bloated piece of crap written by the bumbling serfs of an evil capitalistic megalomaniac.... you made it that way by fx. including DRM.
...and pls. tell mr. Gates that his argument against Linux, that crap about the cost of learning a new UI, also apply to his own fucking operating system and his own fucking office suite.
--
Danger! Furry penguins.
The justice department actually tried to do Microsoft a favor by forcing them to separate the browser from the OS.
But perhaps like a child saying "I don't WANNA!", they haven't yet seen the CLEAR advantages that have long been taught with the simple addage:
By the inch, it's a cinch, by the yard, it's hard.
I am sick to death of behemoth OSs. They take forever to install, they take forever to maintain, and how much of it do I regularly use?
Kudos to the OpenBSD team and similar efforts. Do one focused thing and do it well!
Come on people! K.I.S.S.!
"We think people rightly feel that once they buy something, it stays bought," --Suw Charman, Open Rights Grp
Call to the mods would be justified, except for the fact that he is right.
It may be slightly offtopic, I agree, but the discussion was (and I rtfa) about windows vista slippage. Now, Microsoft makes software to make money. And they are making Windows Vista to make money (ask any MSFT investor). The problem with slippage, bad management, code complexity, and a culture of not telling the truth directly affects the ability to sell the software, which directly affects invertor returns. Now, the longer Microsoft waits to ship, the more time competitors have to create more compelling software, and this means that the Microsoft software is less valuable in the marketplace. It's about time-to-market. The longer you wait, the more and better choices your consumers are going to have.
In the GP's case, that has happened a long time ago. But it is starting to happen more and more for regular users. And that is why MS wants to ship Vista ASAP.
"Piter, too, is dead."
Forgive me for commenting on the presentation rather than the content. I really tried to read the article, but the randomly emphasized phrases made it really hard to concentrate on what was actually being said. I know that it's common to use bold font to emphasize key phrases but when you emphasize half of every other sentence it loses it's effect.
On the other hand, I bet that this guy is a Wizard at PowerPoint.
If I don't put anything here, will anyone recognize me anymore?
Wrong. By announcing a release date, they cause people who might have otherwise switched to another operating system to continue to wait. This is essentially the same strategy that killed OS/2 Warp. Everyone was waiting for Chicago (Windows 95). This was also brought out in their monopoly trial as one of the offending practices.
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]
Did anyone else find this to be quite annoying while reading the article? I mean, geez is it a comic book or a freaking blog entry?