Slashdot Mirror
How Microsoft Develops Its Software
crem_d_genes writes "David Gristwood has a post on his blog that notes '21 Rules of Thumb - How Microsoft Develops Its Software', on which he will elaborate at TechEd in Amsterdam next week. It was derived from interviews with Jim Mccarthy, also of Microsoft. Gristwood: 'As someone who has been involved with software development for over two decades, the whole area of how you actually bring together a team and get them to successfully deliver a project on time, is one worthy of a lot of attention, if only because it is so hard to do. Even before I joined Microsoft, ten years ago, I was interested in this topic, having been involved myself in a couple of projects that, I shall politely say, were somewhat less than successful.' Tips include such features as 'Don't know what you don't know.'; 'Beware the guy in a room.'; 'Never trade a bad date for an equally bad date.'; and 'Enrapture the customers.'"
I posted the following on this guy's blog comment form, and I thought some folks here might agree with it... Yay/nay?
A worthwhile and insightful read (and it's about to get slashdotted). You use the phrase "great software" frequently. I post this sincerely and do not mean to troll. Since you are a MS PM and/or dev, there seems to be three possibilities:
(1) MS consistently makes "great software" and you are, therefore, content to be a MS employee.
(2) MS does not make consistently "great software" and you are, therefore, either unhappy at MS or long to be project group that makes "great software".
(3) You and other people (myself included) have dissimilar meanings of "great software".
In short, I believe possibility (3) is the case.
G-Force music visualization
Sorry.. you knew it was coming.
Enrapture the customers
Shouldn't that be shrink-wrapture the customers?!
They will never make it without open source. No one will even take them public, and I am still waiting for the day when Microsoft hits at least 1 million dollar in revenue for the quarter.
Only open source represents a viable business model, ask Mandrake, Caldera and VA Linux.
Compare and Contrast "21 Rules" with The Mythical Man-Month Revisted.
Mod Karma -1: I sed bad wurds. If I cep my mouf shut, I wud be at riyses.
While Microsoft doesn't consistently put out the best products they're capable of, I don't think anyone would stoop so low as to say they put out the WORST product out in the market. As such, it's worth considering how they go about making their software, since it's a difficult job, at best, to get a group of developers to deliver anything. Any tips we can take away as a collective whole would be helpful to us in our larger goals.
I guess that's proof that M$ programmers actually go on dates!
It is not our abilities that show what we truly are... it is our choices.
"the whole area of how you actually bring together a team and get them to successfully deliver a project on time"
When was the last time Microsoft actually delivered a product on time?
So true. And "in a public place" is definitely an important part of that - when a build fails, everyone should be able to see the compilation error.
The Army reading list
does it have anything to do with "an infinite number of monkeys"?
'Don't know what you don't know.'; 'Never trade a bad date for an equally bad date.'; and 'Enrapture the customers. Hasn't Microsoft violated every one of those rules, even recently? I'm not trying to be flippant. I just can't take a symposium on software development held by MS very seriously. What I would really, really like to see is a conference in which some developers from MS discuss how they deal with damage control on a daily basis. I think that would drum up some interest.
Don't be a looter...and yes, I know that it's spelled with an "A" instead of an "E".
So, that's a list of 21 things *not* to do...
Why do you think new XP updates come out all the time?
With its eye's closed...
Come on... you got the correct form of "its" but you screwed up on the plural form of "eyes"?
You can do better...
Casual Games/Downloads
If that's the case, just wait until someone comes along and open them. Microsoft will be the single biggest software corpora... err wait a second.
In all seriousness though, they are actually starting to open their eyes now and realizing that security is going to play a huge role in their continued success to develop software. I think they will still continue to be on top so long as they can evolve. So far they are beginning to... Let's look.. First was a more secure approach to computing, now they are starting to get more serious about searching techniques...
Hmmm.
To be fair, not all MS software sucks ass. I, for one, prefer Word over any of the open source alternatives for its quick load times, functionality, and compatibility. Yes, the compatibility is only an issue because of MS's shady business practices, but we have to accept the fact that if everyone uses a format, we have to be compatible with it.
the whole area of how you actually bring together a team and get them to successfully deliver a project on time, is one worthy of a lot of attention, if only because it is so hard to do
Not being funny, but can somebody point out the last time Microsoft actually brough a team together and managed to deliver a project on time. Every major OS release, every service pack, every single project they have ever produced seems to have been delayed. They are the antithesis of "release early, release often" but then they having paying customers as opposed to us guys...
Anyway, call my cynical, but I think I can find better sources on how to program than the Microsoft team.
How Microsoft develops software:
(1) They notice a great software idea by another company.
(2) They ignore it.
(3) They realize it's big.
(4) They copy it.
(5) They "bundle" this software in the next version of Windows.
(6) They eliminate the competition using their desktop monopoly.
Number (5) can be substituted by "They buy the company".
Microsoft doesn't develop software, they copy or buy.
Well, I know the guys over at Microsoft are all thumbs, but 21?
Damn, I've been posting to Fark too much, I forgot that the comment window isn't WYSIWYG.
Readers, please insert break tags at the appropriate places in my parent comment.
There is no mod option "-1: Disagree" for a reason. "Overrated" is not an acceptable substitute. Post something instead.
.... I don't know if this is a things to do list or examples of things *not* to do - if the result is software of M$'s quality!
Quote:
12. Portability is for canoes.
'nuff said.
I find point 12, "Portability is for canoes" either self-serving to Microsoft interests or an interesting insight into their thinking process.
I fight this idea all the time in terms of supporting more than just IE on a web site's design ("it has 95% market share, etc"). I've seen it in the past on supporting Macintosh platforms, and now I observe it in the industry as a whole in driver support, applications, games, etc., when it comes to Linux.
Maybe I'm taking it too far. Portability can be hard to manage and achieve, but somehow I think if this was coming from the purveyor of a non-dominant OS platform player it would sound a little different.
Overall, I liked the article. Nice to see some more analysis of success factors in project management.
count the number of "f*ck" in comments for news M$ software ?
'21 Rules of Thumb - How Microsoft Develops Its Software'
21? There's a bad joke lurking there... "all thumbs".... hmmm...
Here's how some of the other guys did it.
The Unix Philosophy
I think Linus has proven the effectiveness of that one, and Eric S. Raymond happens to agree with me ;)
Zero KNOWN defects most probably means inadequate testing, poor quality control, or management that kills the messenger, so no one reports problems.
NT 4 shipped with 65K defects?
The only thing Microsoft never makes a mistake on is Billy Gates' take home paycheck.
wake up and hold your nose
It's as though you people think that MS are the only people who write code that contains bugs.
What rubbish. Every company produces buggy software. MS is actually one of the better companies. They actually have a quality control system and don't release software unless it's reasonably stable.
Sure, you can say all you like about their monopolistic practices, but as far as basic stability goes, they're a lot better than most of their competitors.
first they make diagrams using fisher price blocks, then they write their first prototype on an etch-a-sketch. If that etch-a-sketch sand holds firm under 'rigorous' testing standards, it's ported to windows under VB and released for the masses!
Compatability should never be used as the reason, though, since this is a one-sided argument.
E.g. "Women are not as good as Men, because they aren't Men".
No reason, just some words put together AS a reason.
All we know for sure that is that when Microsoft needs a new product, Bill Gates goes into his High Tower of Closed Sourcery with 15 sheep, Steve Ballmer, a technology company with an established product, and an Enya CD.
When he emerges, two months later, the new MS product is ready for market, the sheep have been trained as VP's, and the technology company is dead.
--
http://www.livejournal.com/users/gymbrall/
12. Portability is for canoes. While clever QA management can minimize the burden somewhat, the complexity of multi-platform support is beyond the reach of most development organizations. Maybe this proves that OpenSource is after all a good development model. What has been achieved by GNU, portability, is, according to this development specialist at microsoft, beyond the reach of most development organizations. Only a commited team, driven by computer science can achieve portability. If the development is $$ driven, portability is beyond reach.
I do most of my good dev alone in a room. I even make deadlines! I used to work for someone who used to work at JPL in the 1970s managing software development. One developer would ride his Harley Davidson wearing a cape and goggles and lock himself in a room with the necessary hardware and ask that Twinkies and Coke be left outside the door. They didn't see him for a week, but the code was good. It was for the Voyager program, so we know it was good.
There's a difference between not trusting an ex-frat boy alone in a room and a responsible software developer in a room. Treating everyone on a team the same just breeds discontent. If people work well alone and can be trusted to do so, don't make them waste their time in meetings.
I'm in the hole of the broadband donut.
we all heard was XeRXeS-TCN furtively lapping up some karma points by doing some brown nosing.
6. Beware of a guy in a room.
Linux was written BY the guy in the room.
That's the whole difference in a nutshell.
Check out my sysadmin blog!
"1. Don't know what you don't know.
It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you..."
Did anyone else think of Rumsfeld's infamous mindfart (for which he won a Foot in Mouth award) --
"Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know."
Eerie.
Big Daddy, Johnny, Burp, Aunt Zelda, Scott, Slurp, Big Momma
Yeeeeesh, that's one of the basic priniciples in Software Quality Assurance.
Hey mods what's next?
How about a posting on a perpetual motion machine?
He speaks favorably of the enemy.
Linux is good. Linux is great.
Anonymous Coward #214435 at your service.
Not only does it load quickly, but it also unloads quickly! Hmm...come to think of it, the auto-unload feature isn't really that helpful... Yes, Word Sucks Ass.
Does this include putting flight sims in a Spreadsheet package?
I recognise most of these rules from here - note the publication date.
Quite a good book. The things being said are good. The way they are said is terrible. Very poor writing.
One of the better quotes:
"Most software is a renewal business. Customers buy multiple releases over a relatively long period of time. As a consequence, the market has a deep understanding of your software and its flaws, and your organization and its flaws. Often, the market has grown uncomfortably dependent on software that doesn't meet its needs. In many software situations, customers spend hours per/day uncomfortably shoe-horning their lives into your product. As a consequence, they crave your understanding, and will respond enthusiastically to the least sign of it. Normal success, meeting customer expectations, means to improve the most outrageous and flagrant violations of their needs from version to version. They will likely stay with you if you are faithful about that, though they may well be sullen if not mutinous."
Whether or not compatibility should be a reason when choosing software is irrelavent. The fact is compatibility is the reason 90 percent of people choose software. All they want to know is "Will my favorite game work?" or "Will I be able to open the files my friends send me on MSN messenger?" And, since most people run MS operating systems, most people choose (or just use because its pre-packaged) MS software. But everyone knows that already anyway, I suppose...
#12 claims bluntly that supporting something becomes so much easier when you only have to support it on one platform. From one perspective there's a certain truth to that, and from another perspective it's laziness. But contrast it with #20.
#20 says that the idea has to be shared as completely as possible between everybody in order for everybody to help out as best they can to making the idea a reality.
"Things become easier to support and test if they follow certain specific guidelines, and with a common implementation, everybody can follow a given idea better." Sure, it looks good on paper, and it makes a fine creed for developers, but with Microsoft, that's where it comes to a screeching halt. Because out in the real world:
Hey, nice standard! Mind if we grab it away from you and run this way with it?
It's both weird and wrong seeing people in Microsoft talking about ideas and commonality of vision when in practice the company as a whole so copiously defecates (both buttocks blazing, as it were) on any standards that they don't already have a headlock on.
You cannot truly appreciate Dilbert until you read it in the original Klingon.
22.) Have an assload of money
What are you arguing against? I don't use Apple software either, for the same reason. But they have yet to claim that Platform-independence is impossible anyway.
What I enjoy about Mozilla Firefox is its ability to run on any platform I might choose to run - or be coerced into running.
I would have to agree with you on this. In my experience, portability takes more time but (generally) ensures quality. What breaks on Linux might not break on Windows, exposing a potental problem. I find more bugs in my code by porting than with any other bug-hunting technique. Many are minor and often don't even affect the user in that exact revision of the app. BUT, it's these little things that cause major problems down the road when I modify or change certain features.
For a commercial example, look at Quake 3, I think Carmack's portability (Win32, Linux, MacOS Classic [and later, Mac OS X]) helped a great deal. Q3A was fairly lightweight for its abilities and ran decent on just about any platform with a decent graphics card. (Now we're getting into hardware details, but I digress)
1. Don't know what you don't know.
Yes, and I would also add that feigning ignorance is much safer than feigning self-confidence, and it helps projects to thouroughly research information that is even considered known.
2. Get to a known state and stay there.
I disagree. I think we should accept that we are only ever in a state of the unknown, so that we may prepare for the worse. Don't stay in a state of the known, because then you are ripe for the unknown to come up and bite you on the ass.
3. Remember the triangle.
Resources, features and the schedule are indeed important, but I would also add that there are core features that must be adhered to in order to prevent disasters, which are not features, but critical systems. Sometimes companies like Microsoft will push for more and more features, when a much simpler system will work better and have stronger core competencies.
4. Don't go dark.
I would have to agree with this, but it could also be identified as avoiding feature creep by keeping it simple-stupid. Microsoft adds too many features that require a plethora of miniscule details in order to work, and that often throw off stability of the rest of the system in doing so. Going dark in some areas is going to happen, so I would put that you should go dark wisely, by accepting that at times in the project the team will be in a state of the unknown. Ensure that core competencies are structured correctly to accomodate individual feature additions without delays or growing instabilities. What it comes down to is smart planning and a lot of foresight, but even less features, but enough to get the job done.
5. Use zero defect (ZD) milestones.
I disagree. I think every milestone has to be understood completely for what it is, but it's got to be bug free or it's a fail, in my books. And you should understand the milestone failures along the way because that's part of team building. If you code up a module as one of your milestones and it has a few bugs, you have to track down why they are there and set that as a new milestone -- not skip to the next official milestone.
6. Beware of a guy in a room.
Read Donald Trump's book, How to Get Rich (2004). There is a part in there when Trump talks about a guy who is constantly late all the time, who isn't speaking with employees, and isn't working as a team member properly. Some employees start complaining, and Trump informs them to ask the guy if he needs his laundry picked up or a coffee or lunch brought to him. Trump reminds them that the guy started acting this way just a few months before a multi-million dollar idea was worked out, alone in his office. He says that whenever the guy acts like this, he's about to shake the company. You have to accomodate programmers like this too, and to do so, you can't be looking over their shoulder all the time. I think you should not beware of a guy in a room, but you should change your schedule to accomodate them, and ask for updates from time to time. You have to trust your people or it won't work.
7. Never trade a bad date for an equally bad date
I would agree with this, but if possible you should follow the Id Software motto, when it's done, instead, because only then will you reach the zenith of design and programming practice. Just don't take it too far like some of the other companies with games due out in the late/mid nineties that we're still waiting/not-waiting for.
8. When slipping, don't fall.
Duh.
9. Low tech is good.
Only if you're at Microsoft, because that's all you've got. *zing!* Seriously... the guy says, "A smaller effort is almost always more desirable than a larger one." Can I just say that it reminds me of the commercial with the underachievers? It hinges on putting forth a paced effort, not a minimal output. Sometimes you have to do some work.
10. Design time at design time.
The dangers of knowledge trigger emotional distress in human beings.
"Shipping" probably only applies to closed, static development models, where by a mysterious black box is expected to produce a working product by a certain deadline.
For open, dynamic, evolving development models, those rules apply better, though their goal would not be so much "shipping" as actually "developing".
I have the impression that the article would get less cynical comments here if it were written by someone from a different company.
It really contains good, simple principles. My favourites: "Beware of the man in the room" is a very realistic example. And so is "don't know what you don't now".
Tom
Start
|
Alpha version
|
Enough bugs? - No - Add features
|
Yes - Create a separate product to deal with it
|
Beta version, release as golden master
|
Stop
Come on, Open Office takes over 30 seconds (well, i've never timed it but it has to be near there) to load on my machine where word takes less than 2.
12. Portability is for canoes.
And system software.
Portable free software is in the process of dismantling his company. You would think he would acknowledge that.
an ill wind that blows no good
From Article: Portability is for canoes. /me stares dumbfoundedly at one Lin/Win software project before minimizing the window and stares at the _other_ Lin/Win project he's working on... :p
Damm it! I'm 19 thumbs short.
Brocklesby Park Cricket Club
Actually, isn't one of the strengths of Linux is that it ISN'T written in a vacuum?
I am very small, utmostly microscopic.
Release often may be good for some. But it can get kind of annoying to have to keep upgrading, many end users want stable software that works, not something they have to upgrade every week to fix the latest bug. Although this is better than the bugs being found and not fixed for months. Also if you have to buy every release it gets kind of expensive.
What strikes me about this article is how there's such an emphasis put on meeting critical dates, but that Microsoft is routinely late in delivering their software when they say they will.
How much value should we give to these "rules" if they don't actually work?
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
No, it wasn't. I refer you to the Ken Brown book.
I'm sorry, but I don't think the "rule of thumb" maxim can be applied 21 times to the same area.
"Rules of thumb" are what you use when you don't have any other accurate mechanism, or you just want to estimate...
Perhaps the quality of Microsoft software can be traced back to the "21 Thumbs" rule they use.
...DOS isn't done until lotus wont run.
Huh? He's arguing against solitary development and for "They must be capable of performing on a team, making their work visible in modest increments and subjecting it to scrutiny as it matures." and you're invoking Linus as an argument against him?
What I'm listening to now on Pandora...
is much like how sausages are made:
Best not to know how.
So rise up, all ye lost ones, as one, we'll claw the clouds.
It's the guy(s) in the board room I'd worry more about.
You don't need a lab to make mud.
Maybe he's dyslexic, you insensitive clod!
I'm in the hole of the broadband donut.
Every ounce of psychological, emotional and intellectual energy is being consumed in the work itself. Teamwork, in this case, is an insignificant factor to a person immersed in this sort of creative experience.
Doesn't this sound kind of cultish? While teamwork is good, this seems to say to say you should subjugate yourself to the greater good...
Anyone else hear: nana nana nana nana Leader, Leader, Batman, uh Leader
Remain lost in hidden worlds where I reign. Head engine and caboose in my toy train...
Once upon a time, I worked for a hardware company, where I started in their support call center. One of the first things I was told is to never use the word "problem" and instead use the word "issue."
Why? This is what the idiot trainer had to say:
"Problems have to be fixed, where issues get resolved."
It's complete marketing bullshit, and we all knew it, so we would constantly be saying smartassed things like "This caller is causing me issues" and "what the hell is your issue, buddy?" and in the IRC server we had set up for in-call chats, the standard thing went like this:
tech1: MainstreamVidCard is giving a black screen with an hourglass and locking up... wth?
tech2: that card sucks. Tell them to get the übercard.
tech3: LOL
TeamLead1: Try new video BIOS and drivers. Go through BIOS settings, and tell them to stop overclocking.
tech2: LOL
tech3: LOL overclocking
tech1: ok thx!
TeamLead1: NI.
We couldn't say No Problem, so we said No Issue instead. What a farce.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Never have I read so much, and learned so little.
I actually got tired of saying "DUH" about half way through it and gave up.
I'd like my bandwith back please.
That only works for free software.
Release early - ie; when you KNOW it's unfinished.
Relase often - ie; it's so full of bugs and unfinished you need nightly builds to work them all out. At this point, you're releasing forever because now you have yourself a moving target with no set "completion" point, or any goal you're trying to achieve.
Listen to your customers - And if they complain just say "well it's free so fuck you if you dont like it". Seriously, no OSS projects "listen" to the customers.
If they did "listen", Linux wouldn't be a monolithic kernel, so I could download binary drivers for my new video card without recompiling it. Guess what, nVidia or ATi are never going to want to open their drivers' source. Doing so would essentially give away all the IP they put into designing their GPUs. A month later, some fab is set up in taiwan producing Radeon clones.
Samba would be able to function as an Active Directory Controller - it can't, and it's not even a project goal, NT4-style is apparently good enough, they haven't even plugged the gaping security holes in the old scheme MS did. Ie; you have to disable "require sign or seal" to join 2k or XP to a samba domain, essentially, you don't give a rats ass about verifying the authenticity of the MD4 password hashes that get bandied about plaintext on the network.
Open source "works", but not all of the time, and not always how you want it to.
I don't need no instructions to know how to rock!!!!
This is the danger of taking a line out of context. Really what that line means is a guy locked in a room for an indefinite period, and at some theoretical time in the future he releases his code to everyone else on the team and it magically works, and works well.
It works fine if you're the only developer, it works horribly if you've got an entire team developing the software. People on a team need to touch base, and if there's just "guys in rooms" that aren't showing progress, taking criticism, etc, the whole thing can implode.
You're right that linux was initially written by Linus, but he also wasn't working as part of a team at the time.
AccountKiller
Wow, the Mozilla developers could really learn something from Microsoft here. Maybe they should contact MS and ask how they can switch from a build environment that supports 10(*) or more platforms to one that just supports Win32.
While they're at it, maybe the IE core team can help them out with how to introduce Mozilla features that allow arbitrary, hidden software to be easily and automatically installed on the user's machine.
(*) Technically, I suppose the Mozilla team builds for 3 platforms (Win32, OS X, and Linux) which does probably limit the amount of QA testing required, but this is still usually 3x as many as the Microsoft people deal with, and the build system enables at least 7 more platforms on top of that.
-- Fratz, human
I beg to differ.
The 'guy in a room' is a metaphor, not a physical description. It's someone who isolates himself for an extended portion of the schedule, interacting only at the end to deliver the results.
Maybe Linux is a guy in a room, but that's only the physical side. Linux works and advances because he's extensively and intensively in contact with kernel developers.
The living have better things to do than to continue hating the dead.
OK, for the humour impaired: AUTO-UNLOAD MEANS THAT THE #%&*ING-THING #%&*ING CRASHES!
12. Portability is for canoes.
And system software. Even discounting the added development burden, with the addition of each additional platform the job of QA increases substantially. While clever QA management can minimize the burden somewhat, the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible.
Wow...yeah, that's Microsoft alright. Don't bother writing software for anything but the One True Platform. Amen. Never mind the fact that Windows runs on...hmm, lets see...x86 and ummm...well. I suppose there might be a few others, but I couldn't tell you for the life of me what they are. Linux on the other hand...
If you're writing a client side/GUI app, you can get away with this mentality. Try it on the server side and your product goes nowhere. I believe this is one of the reaons that Microsoft has had (and will continute to have) problems getting entrenched in the Enterprise computing market.
I suggest instead:
Don't bet on the S. S. Ti^H^H Microsoft, bet on a platform that you know will 1. stay afloat and 2. you can afford passage on forever.
microsoftword.mp3 - it doesn't care that they're not words...
It's a decent book from the early 90s. Most of those rules are in there.
--
Marc A. Lepage
Software Developer
Consider that Microsoft developed Windows (Mac), Excel (Lotus 1-2-3), disk compression (Stac), IE (Netscape) and the rest using other people's work as templates and the true value of #1, #2 and #10 is revealed:
1. Don't know what you don't know.
2. Get to a known state and stay there.
10. Design time at design time.
Then there's the way they "develop" products including MS-DOS, PowerPoint and Visio...
3. Remember the triangle. resources (people and money), features and the schedule
The lessons of Microsoft "development methodology" belong in university commerce and economics departments, not CS.
22. Change direction then convince everyone that was the direction you were intending to go in at the start.
Like with portability.... NT was supposed to be the portable OS, on MIPS, PowerPC, Alpha. But as that didn't take off, now 'portability is for Canoes'.
No company can match Microsoft for blatant and unabashed hypocracy. This article is a good example.
I can't understand why /.ers are so critical of Microsoft developers. They're one of the hardest software companies to get involved with, and make some of the most amazing stuff (granted, there's been a lot of crap too). You should see for yourselves how high their internal standards are. Yes, IAAFMIAAMG (I am a former Microsoft intern and an MIT grad).
Yeah, it's a good model. Unfortunately it doesn't really work for commercial products.
Imagine if a new versions of MS Office came out at the same rate as the Linux kernel - almost no one would have enough cash to keep up. It's also one of the reasons FS/OSS software evolves so quickly, the cash problem doesn't exist (free beer) and bandwidth is cheap.
then you are biased, like me... My father works almost exclusivly with word-people but they are having trouble with different versions of word. I work with people who runs solaris, os x, linux and windows and I have never had any trouble with anyone of them by using openoffice pdf-exporter (although I mostly write in latex and convert it to pdf). Everyone is having trouble with words stupid formats . When people need to work on a document together they are almost bound to use the same wordversion if they are going to use word and that is seldom possible if its alot of people as everyone don't have the computing power to use the latest and/or is perfectly happy with their old version and have no urge to buy another newer version.
-1) DOS isn't done until Lotus won't run. True or not, it sure seems like it. Anyone wonder about XP-SP2?
The world is made by those who show up for the job.
Dear AC
Thank you for the address.
Yours sincerely,
Spiderman
Assuming that these rules describe how Microsoft design their software, then I have to say there's nothing wrong with them. For example, the one platform issue - Microsoft has an opportunity to design for one platform, they know they can get away with it, and that's how they do. So the rule works for them.
However, whether these rules are applicable for others is another question whatsoever. Microsoft's goal is to monopolize the market and get insane profits, and well, not give a shit about anything else. So if you look at these rules from that viewpoint, they make perfect sense - but not much else. That's why I think the author should make it more clearer that these rules apply only for a company that has a market share comparable to Microsoft and has the same goals.
So, in conclusion, these rules are mostly useless for anybody but Microsoft.
True, Microsoft has issues with software development, But, wouldn't ANY publicly traded company (or private, for that matter) who had the financial resources do the same thing? You see something that might make you money or enhance your existing product; you license it or buy it. So what?
If it compiles, it ships.
One place I worked had a rule that no bar on the project plan Gannt chart could be more than two weeks long.
The lone programmer in a room working against a three month deadline is a disaster waiting to happen.
That way, you don't know if you are behind schedule for three months.
At that point, they could still have another three months of work left to do.
If the programmer is left alone for a week, you can find out how far along she is a the end of the week.
If she is not done, you can ask if there is anything you can do to help her finish the task.
That might include having her check everything in to revision control and giving part of the task to someone else.
So worst case, you slip a week.
Having a critical part of the software being built by a lone person with a long deadline is really bad news unless you get lucky.
Another way to think about it is that you get to find out if the project estimates are reasonable a lot sooner.
If the first task took 50% longer than estimated, don't say "We'll make it up later on in the project." That is a sign that you need to increase estimates or remove features to meet the project deadline.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
Shipping is just the final milestone.
How wrong! Shipping is just the 'start of adult age' for software.
There are only three things that you are working with as a development manager: resources (people and money), features and the schedule.
So people are things, and shipping is the objective... Wow! Let's call it productivity minded!.
I don't buy this line, after more than two decades actively programming, I prefer the 'keep the people on' motto, really. Even more, I can hardly think on being 'proud' of making some software product if the people involved were considered 'resources'.
What's in a sig?
But we all know Microsoft software has some severe problems. Security - gets viruses, spyware, trojans easily. Crashes.
Is this because of the design process or for other reasons? Here are a couple reasons why Microsoft software could have all these problems in spite of a good design process:
- Keeping backward compatability at all costs. This has been a key to Microsoft's success. It makes for ugly code but it keeps customers. It also leads to security vulnerabilities. If the internet ready version windows was designed fromt he ground up for security, it would have been a lot different.
- Hairballing stuff together that should be seperate. IE is hairballed into to OS to work around anti-trust law. Now the media player is hairballed into the OS for the same reason.
Religion is the main cause of atheism.
> I think the focus on features, rather than on quality, is a manifestation of what I call "bookkeeping syndrome": something is adopted as a metric not because it's important, but because it's easy to count. Using quality as a metric is harder, because it requires actual thought about how the product ought to work, and about what really matters to the potential users.
I have to agree. I'll also add that Microsoft, being the largest corporation around that I know of, has taken into consideration the general customer's purchasing department strategy for doing *their* jobs. They ask, "what can it do?" They ask, "what can the others do?" What purchasers fail to ask, more often than not, is whether we need all that crap, and if there is something cheaper, or Open Source, that can do the job better or as effective. But that's changing, isn't it? This kind of thinking has to change because the companies around the world are evolving to understand Microsoft, and they are understanding the problems with Microsoft as being more than run-of-the-mill computer problems.
I think what the Open Source community did that pushed them ahead of any other Microsoft competitor in terms of value, and units, is they took the purchasers out of the process, by providing free products that could be licensed for support. It becomes a nobrainer for a purchaser, provided they aren't too deep in Microsoft Slurm (note Futurama lovers will get this).
The dangers of knowledge trigger emotional distress in human beings.
These "21 Rules Of Thumb" are distilled from McCarthy's "Dynamics of Software Development" book, which has been on the bookshelf of almost every dev lead I've ever worked with or known. You could have a similar "argument" about how good IBM software is (WebSphere?), but at the end of the day, if you're doing it to critique The Mythical Man Month, you're going to sound really dumb.
More importantly, all bitching about MSFT quality aside, McCarthy was dev/program manager on Visual C++, which is not a poorly-regarded Microsoft product (it's one of the best compiler products on the market). There are extremely successful products --- successful on every axis --- that come out of Microsoft. Visual C++, and McCarthy's book, represents one of them. Microsoft Excel, and Joel on Software, represents another.
Microsoft is a huge company with an enormous talent pool and many very qualified, very effective well-jelled teams. You do not sound credible when you try to tar them with the "Microsoft is buggy crap" brush, especially when you're arguing with McCarthy or Spolsky.
The first point is interesting; apparently, Microsoft doesn't know the majority of development work is multi-platform. I guess that in the Microsoft Universe(tm), if Microsoft can't do it, it can't be done... I am currently working on a rather large development project that will be used across at least two, if not three, major platforms. The overwhelming majority of developers must support multiple platforms because:
And the second point? Granted, Linux may be able to do multi-platform support rather well, but anyone who demands multi-platform support from Microsoft will get laughed out of the boardroom. It's not like they're going to care; you aren't spending their money to develop your application, and if it doesn't run on different platforms, it only increases their monopoly.
The society for a thought-free internet welcomes you.
I don't know about you, but "issue" sounds even worse than "bug" to me.
Maybe a company just wants to use a more professional term like "issue" rather than "bug?" I see nothing neutral about the term. I think you just want SOMETHING to bitch at Microsoft for.
I could give you endless instances of double-speak in the OSS camp as well. Where's your bitching about that?
Funny, I've always heard it as Cost-Schedule-Performance. It is another manifestation of the fundamental difference in thinking by microsoft that features should replace performance, or are synonymous with it.
I do security
I've received several top-tier MS products (including BackOffice Server 4.5) with setups that included such obscure syntax errors as "**REMEMBER TO FINISH THE SQL INSTALL SCRIPT***". Or, floppies using a new "DMF" (no fat) format... bundled with a setup.exe and lzexp on disk 1 that couldn't read them.
Granted, these scripts aren't compiled... but clearly, they weren't even tried.
So no - "If it compiles, it ships" is NOT true.
help me i've cloned myself and can't remember which one I am
I believe the problem in a nutshell is this.
Software rarely has good architects, it has plenty of people who can glop code as they read their in 21 days book and slept through their CS classes, but so very few who can create a project, make the foundation for others to build on.
Your project should be structured so everyone can be the crazy guy in a room, everything should be a module with a common agreed upon interface created during the design phase and all of the tools to test each module should be written before the actual modules are, so everyone has a clue as to specifically how they communicate, each module should be small enough where if the crazy guy in the room doesn't emerge on-time, he's doing something wrong, spinning his wheels, etc...
Problems will always occur, things rarely just work, and even a team will require collaboration at the end to get everything working smoothly.
I don't like the analogy reinvent the wheel in software, there's almost always a better way to accomplish something and if you goal is to crank shitty software out the door, then microsoft's way is the best, but true innovation doesn't come from a team, it comes from an individual locked in his closet of an office.
Why does it take an entire team to build software, doesn't that point to shitty tools, a painter doesn't paint by the atom, why should a programmer write code in anything as low-level as today's languages, especially if we wan't big projects to work well.
Software isn't a sport and doesn't require a team, it doesn't require collaboration, that is hack put in place for poor design and non-existant standards for communication amongst modules.
For crazy guys in a room, look at the kernel module devs, the apache module devs, the perl module devs, the everything should be a module but the rudimentary stuff is the way to go, the crazy guy releases his code, everyone looks at it, submits bug reports or fixes it and the rest is history or profit in the case of a commercial software dev.
that ads on Slashdot are almost always a Microsoft ad? Coincidence? I think not...
"First was a more secure approach to computing...."
are you posting from the future?
Portability is for rafts and other open platforms.
Write to an open platform and your software is portable by definition, because the platform itself is portable.
microsoftword.mp3 - it doesn't care that they're not words...
Microsoft develops its software?
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
Didn't McCarthy write this stuff in a book fifteen years ago? Why is it being posted now?
I'm not certain about #21, "get the team into ship mode". I prefer the model when development happens continuously, and shipping is done on a branch off of development. That makes shipping a sideshow.
However, a lot of bugs aren't evident until the software is stabler than a development branch usually is. Ship mode is when those bugs are usually caught. Does that make it a good idea to pull all of development off of development and put them on bug fixing in ship mode? I'm not sure.
where do I know this from? somehow it rings a bell..
PAT
SEO Test: TIGI und SEBASTIAN - Online Shop - V
I don't want to get into a flame fest
Right.
, but since you claim they don't produce the WORST product in the market, and since Windows is such a large part of their revenue, I challenge you to find:
First of all, the question itself is ridiculous. I can quite genuinely say that Windows XP has never crashed for me or been broken into. However, Linux has frozen up on me several times, and it has had kernel exploits in the past. But that doesn't make Linux less secure or less stable.
The fact that Windows is used WAY more than Linux means you'll get a greater total sum of crashes and breaches, but that doesn't make Windows less secure or less stable. You're arguing a ridiculous premise.
* An OS that is less secure than Windows.
Remember that Slashdot article about how Linux was the most-breached OS on the net? I sure do. A Slashdot editor even modified the headline so it said "Linux Most Attacked OS On Net" instead of "Most Breached" so it didn't look as bad.
* An OS that crashes more frequently than Windows.
Windows never crashes for me. I haven't seen a BSOD since 1999. But, Slashdotters seem stuck in the late 80s and think Windows 98 still represents the stability of Windows today.
I had Gnome crash my laptop under Red Hat 9 the very first time I used it. So fucking what?
* An OS with a EULA more restrictive than Windows.
This is a silly question to throw in. Windows' EULA isn't much more restrictive than, say, IBM's EULAs or Apple's. As if the EULA has anything to do with the operating system itself. Complain about the legal department but not the software development department.
* Software which has slipped the scheduled release date more often and by a larger margin than Windows. IIRC, Microsoft hasn't released on OS on time in the last 10 years.
Yeah, and how late was 2.6 again? Oh, that's right, it shipped a year later than Torvalds said it would. Again, this is a completely ridiculous argument.
I know it's l33t to be a raving Linux zealot, but a lot of people are really getting tired of it, as evidenced by the posts I've been seeing lately that are getting upmodded. I'm very pleased to see more and more people approaching things rationally and fairly now--even if Slashdot editors don't. The very fact that Clippy jokes and BSOD jokes are still upmodded--two things 95% of Windows users haven't seen since 1999--shows you how stuck in the past zealots are and how they won't let go of their old Windows 98 experience. They're competing with old 9x versions of Windows when meanwhile everyone else moved on when the codebase unification to the NT kernel happened in late 1999, and we got Windows 2000.
But, I forgot. This is the "year of Linux on the desktop." Hey, remember that article Slashdot posted that said Linux desktop usage would overtake Apple's in a year? I even had one Slashdotter cite it to me as evidence for a point he was making, simply because Slashdot had reported it. So much for that.
If you're a Linux newbie and you're coming here for tech news, you're doing yourself a great injustice, as everything will be skewed and you will get a huge wrong impression about how the tech world is doing.
Well, duh. It's because most OSS projects have *no customers*
Not all of them, though. Hans Reiser, who works on the ReiserFS filesystem for Linux will be glad to add whatever you want to it, for a price of course. Want encryption, compression, or a better handling of whatever vital task you need to accomplish? They'll do that for you. They'll even help you recover your data after you screw up (they'll help for free if it's a bug). I'm fairly sure you could make a similar deal with most OSS developers.
I'd say that's much better than most companies, since I don't remember MS making big changes their customers wanted. MS these days seems to be going in whatever direction they think is best (DRM, WinFS, etc). Hey, isn't that exactly how most OSS projects work as well?
The rest of your points simply don't make sense. It doesn't make sense for Linux to accomodate nVidia and whoever comes next. Linux would die if it had to stay compatible with everybody's closed source drivers. What about Samba, you know, MS didn't exactly give them a spec to implement. They have to reverse-engineer it.
1. Hire an infinite number of monkeys.
2. Let them type code for an infinite length of time.
3. ???
4. Call the resulting spaghetti an OS.
5. PROFIT!
This post encoded with ROT26. If you can read it, you've violated the DMCA. Handcuffs please, sergeant.
5. Use zero defect (ZD) milestones.
I guess they never follow #5 hehe
My penguin ate my sig
As many here have commented, sometimes the guy in a room can do some amazing work, often in a shorter time than intended. However, customers and product schedules can't rely on the sometimes erratic nature of such prodigies. So I think this statement should be changed to "Don't bet on the guy in a room."
Congratulations, canfirman, your witty use of the word "M$" has solidified you as a scholar and a gentleman. It has raised the intellectual level of your post beyond mere quip to insightful social commentary on the state of our world. You have therefore been chosen to receive the Official Zealot Buzzword Trophy! On its side are enscribed the words, "Trolling like it's still 1998," to point out that terms like "M$" got old in 1998. We are happy to give you this wonderful award, and congratulate you again.
Don't call us, we'll call you.
There is difference between code portablity and its ability to actually run on multiple platforms.
Writing portable code means not using platform-specifics when you don't have to.
Clearly this is not always possible, but data containers, networking libraries, high-level memory managers and data mangling in general usually have no business being dependent on the platform. Even software-based crypto, which is typically hand-optimized for the platform, can be written portable with a very little performance hit.
UI is obviously tough to write this way due to the size of the API it depends upon. But at least it can be kept separate from the datamodel and core engine code, making them portable.
I also noticed that mere considering of portability seems to improve the code quality. It forces the developer to spend a bit more time thinking about the problem and producing better abstractions. And the latter is what makes the code 'cleaner' and the design - 'elegant'.
3.243F6A8885A308D313
"bring together a team and get them to successfully deliver a project on time."
If someone says he and his monkey have nothing to hide, they almost certainly do.
Ok, they don't put out the absolute worst tripe in the industry, so we might be able to learn something from them. You are truly wise.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
There's so much bullshit in this article, you won't believe. I don't know who this guy is, but any MS developer worth his salary would laugh him out of his office over that "Don't go dark" thing. That's the only way to get anything done at MSFT. If you participate in all the meetings that are scheduled for you and get "buyoffs" from everyone you will NEVER get anything done. So it goes like this, you participate in the meetings at first (to make you look good when review time comes) and then you go PITCH BLACK, not just dark and deliver the code. It's always easier to get forgiveness than to get permission.
We really need to define "great software", and when you think about it, that's difficult to do, especially since software is a moving target.
"Shipping" does not involve cvs access, and probably doesn't involve source code access either.
"On time" doesn't really make sense, unless, of course you have been making promises, or have been given deadlines.
1. Study the successes that you see, study those individuals or organizations that have accomplished things similar to which you wish to accomplish, and then apply what you have learned. It's a very good key to success. If were were to learn something from this, we would need to look further than just one company, further than just one manager.
2. Software is a moving target. Some software moves faster than others, and the whole idea of a "snapshot" goes against the grain of a moving target (it's just easier to deal with sometimes.) Software, really, should be an on-going development process, and while it's possible that you might have to slow down the speed of the "moving target" in order to take a snapshot, or make a "release", taking snapshots and releases shouldn't occur to the detriment of the ongoing development process in general, and the current state of development should be somewhat ahead of the snapshot or release. Great software is more like a living organism, less like an inanimate object. The release, or the snapshot, or the "shipping", has traditionally been the main focus, but what really counts, I think, is that the development process be ongoing, and progressing at a sufficiently consistent and rapid rate. Shipping something is just something that happens as part of the development process, a side effect, if you will; the development process is the main focus, the main goal.
I can understand where the individual is coming from, but this is really more like a how-to on how to keep your job as a manager in an organization such as Microsoft - these rules may not work universally in all business settings, in all software development settings, and may, in fact, be detrimental.
What is really needed is more input - more input from employees, from managers, from the managers' managers - from a diverse selection of software development organizations across the globe - then there needs to be an agreement on what is "great software" - obviously, we are currently moving out of a phase where the relatively new world of software and computers has been dominated by one software vendor - it's hard to define "great software" if you don't have a competitive and free marketplace. It's like trying to define "great leader" in a dictatorship. It just doesn't work.
There's no proof - there is insufficient evidence that this will actually work today, and tomorrow, as the world moves towards a more competitive marketplace in the software industry. I certainly doubt that this is going to be very good for turnover rates, and most importantly, will this type of development methodology be successful in ATTRACTING and RETAINING the MOST talented software designers that are out there? I think the answer to that question is obvious.
I think you're right.
Of course "no known defects" doesn't sound as neat as "zero defects" to managers, but it would probably piss off a lot less perfectionist engineers...
Hands up all those surprised to hear this coming out of someone associated with Microsoft. Perhaps the phrase "Applications barrier to entry" rings a bell?
Don't do what Donny Don't does.
I think you should revisit the concept of "simple".
"...bring together a team and get them to successfully deliver a project on time..."
What exactly does this have to do with MICROSOFT??
There is a difference between writing portable code and writing code for a cross-platform system. You will do better if you pick from the beginning the system you are writing for, and write only for that system. You will also do better if you have a set of tools which insists that you make no assumptions beyond those that the system provides.
The sort of non-portability which is bad is when you depend on things which are not always true of your system. This is what leads people to design sites that look ugly with browser sizes other than the one they test with. If you're trying to make a web page, as opposed to an IE page, you need to test against web standards.
The sort of portability which is bad is where you are developing for multiple systems which are different in ways that matter. This is what leads to web sites that work with only IE and Netscape 4.7.
If you need to support multiple platforms, it often makes sense to write two independant versions, rather than try to have a single cross-platform version. Or you can have two versions of the platform-dependant portion, and a common portion whose system is your library. But trying to have a single device driver for both Windows and Linux is just going to be hopeless as well as pointless.
... I think I can safely conclude how Microsoft develops its software:
1 million monkeys, 1 million keyboards
These rules of egoless programming have been circulating on various sites:
Like most platitudes, they apply in some situations and not in others and there are plenty of valid exceptions.
For instance: Treat people who know less than you with respect, deference, and patience -- but don't let them tell you how to do your job.
Or: Fight for what you believe, but gracefully accept defeat -- and when you turn out to have been right, don't let anyone forget it.
Very little time. Less than it takes to write a Makefile for XP. If you use some IDE, like kdevelop, the wizard runs in a few seconds. Then it's just "./configure; make; make install", in any flavor.
But the difference is, if open source does it the resulting product is free to the world. No one is taking our money, no one can decide not to release the source code, etc.
What Microsoft is doing is bad not because it puts people out of business, but because it puts people out of business for the sake of increasing their own pocketbook and strengthening their stranglehold on the market.
To put it another way, if linux puts people out of business, it does so while it increases user freedoms and decreases user costs (and both of these things could potentially lead to greater economic growth in the long run.)
Progress will always put people out of business--it's unavoidable. But monopolies can easily break the laws of capitalism, and so I believe that what Microsoft is doing can no longer be called "progress"...
i do balance mine the whole day but it doesn't seem to help much
"There is nothing more frightful than ignorance in action." Johann Wolfgang von Goethe
I guess there's a certain truth to what he says, depending on how you approach it.
The thing is, you really _don't_ want to be in the business of having to worry about platform-specific concerns for more than one platform in your own code.
If you try, you'll either end up essentially writing your own meta-platform (building and debugging it from scratch, consuming development time better spent elsewhere), or your code will become a mess of #ifdefs and specializations which can only ever be built or tested on obscure platforms (meaning most platforms will always be moderately broken).
What you want to do is pick a platform that lets you run on a range of systems -- i.e. "leave it to your system software".
Inkscape's "platform", for example, is for the most part not POSIX nor Linux nor Win32, it's Glib/Gtk+/Pango/Gdk + libxml + STL.
We still have a number of platform-specific subclasses and #ifdefs (many inherited from Sodipodi), but we're actively working to reduce (ideally eliminate) them.
For example, most recently (in CVS), we replaced the typography subsystem we inherited from Sodipodi with a little bit of glue code on top of Pango.
In the process, we gained a lot of features that Lauris never had time to implement or debug in Sodipodi's private typography library, like using the kerning information specified in fonts, and the hardest parts of support for rendering "interesting" non-Western scripts.
Just be sure that the set of libraries (your platform) which you write to is widespread and well-tested on the systems you care about.
I guess given the systems David's employer cares about supporting, his choice of Microsoft platforms shouldn't be altogether surprising.
DNA just wants to be free...
It's ironic that he titled his article "Shipping Great Software On Time", and he works for a company that doesn't make "Great" software, and is known for shipping it way late.
Ha Ha
JWall: GUI client for IPTables
Microsoft is not honest, they don't communicate, and they products certainly aren't simple.
(OK, MicroSoft is only 29 years old ...)
The first half of MicroSoft's existance seemed to be pretty much "cowboy coding". That is maverick people and teams, slipped schedules, products moving in lots of different directions, lots and lots of vapor announcements. These was due to extreme growth and leaders who were more visonaries, than nuts and bolts software engineers. In the late 980s, early 1990s MicroSoft seemd to get more disciplined, actually shipped product on time, and products that worked together.
This goes not just for Microsoft, but for any other software company.
According to this definition, statements like "Microsoft makes the best software in the world" are 100% true, because they have been the most successful at marketing and selling it.
Engineers have a completely different sense of "goodness" than marketers do. Most hackers appreciate goodness in the engineering sense rather than the marketing sense, hence the expected Slashdot backlash against this blog post.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Where's the commercial OS worse than Windows?
If my job as a project manager is to ship software on time and bug-free, why would I listen to Microsoft, which has done neither?
Incidentally, my mother was a project manager for many years, and she managed to bring every project in on time, beating some deadlines by 50%. And bugs were simply not accepted - the project wasn't done until the bugs were corrected. Microsoft sets its own schedule, and they still can't ship bug-free software on time.
The society for a thought-free internet welcomes you.
Even MS with a team of thousands and a bank account of billions and programmers earning millions CAN'T ADOPT THEIR OWN RULES. Even with all this they still seem to do not better at software development then anyone else. Some of their products are okay but most are not and none of them are on time or on budget.
This is not just MS that has this problem, every software developer is performing badly when compared to the people developing "real" stuff like cars and washing machines. Software projects are delayed, go over budget, have missing features, need "recalls/patches" and in extreme cases just don't do what they are supposed to do.
Perhaps the problem is that software can be patched. Imagine if you PC had to be recalled with every patch like say your car or other appliance. Then perhaps costumers would demand software that worked first time around and company's like MS and others with constant recalls would go out of bussiness.
In short nice list of points, now how about telling us how to actually put them in use? Show us by actually making an MS product with "zero defects" (no known bug list), on time, that enraptures me. Good luck, I don't think it can be done, I don't think anyone can.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
You actually replied to my post.
Maybe you're just trolling; I've never used Mac OS 9 for longer than a few hours, so I don't know. If you aren't, I'm glad I didn't "switch".
The society for a thought-free internet welcomes you.
There are only three things that you are working with as a development manager: resources (people and money), features and the schedule.
Funny, I remember that one from XP theory, but it was a quadrilateral, then. Resources, Scope (features), Schedule, Quality. Sometimes one has to balance scope and quality and can't compromise on scope, the quality has to go -- thread safety, scalability, code size or whatever metric you may decide can be ignored...
I imagine I will be getting a lot of flak from my fellow programmers; no one likes doing shoddy work, myself included, but sometimes it becomes unavoidable.
I was more alluding to the fact that in the very beginning, Linus developed the code by himself. He was the "guy in the room". Then he posted it on C.O.M. but it started with one guy, not a planned group activity.
Check out my sysadmin blog!
If you're writing a client side/GUI app, you can get away with this mentality. Try it on the server side and your product goes nowhere. I believe this is one of the reaons that Microsoft has had (and will continute to have) problems getting entrenched in the Enterprise computing market.
I don't think you can get away with this, really. For one thing if you are writing only for Windows you are then ignoring a pretty attractive market - Mac users. The marketshare may look small but in general Mac users have a bit more money to spend, and additionally you are not going to have as much competition.
But the other aspect that should lead a company to produce portable code is that by doing so, you avoid tieing your own product to any one OS. Then when that OS upgrades, you are probably going to have an easier time having it work on newer versions - plus if other OS's become more popular over time your product is not weighted down to just the one OS.
Basically, the disipline of trying to make code work in multiple places will have other more intagible benefits - I think it's a mistake to discount this.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Right, my entry was more of a joke and wasn't really to be taken seriously. I knew what the author meant, it was just a (hopefully) comical off the cuff remark.
Check out my sysadmin blog!
..that the article is missing the illustration with a 21-thumbed Microsoft developer on it. My imagination is running wild..
Might also explain the quality of their products - ever tried to do code using thumbs only?
And then of curse there is speculations about exact location and function of the 21st thumb...
How Microsoft Develops Its Software
*cue monkey scene from 2001: A Space Odyssey*
Burn the land and boil the sea, you can't take the sky from me
"Don't know what you don't know" -- David Gristwood
I don't know about you, but to me, if you say "Don't know what you don't know", it sounds like you mean "Be blissfully unaware of the things which you do not know".
Whereas what he means is apparantly that you should know very clearly which things are unknowns. Not that you should be unaware of them. To me, the proper way to express that concept in English is "Know what you don't know". And I'm pretty sure I've heard people say that exact thing before in other contexts.
Maybe this is where all the problems come from in Microsoft software. The top guys are all saying fervently "Don't know what you don't know!" and the developers are all thinking that means they are supposed to stick their heads in the sand and ignore the completely undeveloped specification, ignore bugs that haven't been found, and proceed full speed ahead with coding.
At least that's what I would think if my boss was always prancing around saying "Don't know what you don't know".
I personally am a Mac user, but that doesn't mean I'm blind to the faults of Apple or the good work Microsoft is able to produce...
Apple: 10.2.8 anyone? Weekly kernel panics on my G3 Pismo. Finally went back to 10.2.6.
Apple: 10.0, 10.1 -- not nearly ready for prime time
Microsoft: IE 5.x/Mac -- at the time, probably the best browser for OS 9
Microsoft: Office 2000 for Mac (OS 9) - more capable than (and fully compatable with) the Windows version at the time, from what I read.
I have always wondered where Microsoft gets their customer requirements from. If you are producing software used by nearly everyone, how do you choose who your "users" are, and better yet how do you get requirements out of them? Do you think that they consider large businesses as their main customers?
As far as I can tell, Microsoft doesn't have to answer to anyone. Therefore, they may generate their own requirements for their software.
My beliefs do not require that you agree with them.
Shipping great software on time is a difficult but not impossible task.
How would he know? He works for Microsoft!
And I still maintain this is not a troll!
Look at the issue of "on time". Does anyone remember why it was called "win95"? It was because it slipped for years! Bill G. finally called it win95 to reassure customers that it actually would ship in 1995. As it was, it finally shipped in Nov, '95. You can't get much later than that! And what about WinME? The only reason for that product's existence was because the NT rewrite was taking so long. Almost 10 years after the win95 fiasco, Longhorn has been pushed back and scaled back and it still won't be out for another 3 years!
Since I've mentioned WinME, let's address the question of "great" software. Was WinME any example of that? Enough said! What about the complete abortions that IE and Outlook have become? What about IIS? These are not examples of products that "shipped with a few bugs", these are products that have been plagued with compromises, security breaches and bugs since they were released. And there doesn't seem to be any end in sight! Just today, there was another trojan that used exploits in both IE and IIS. Sine it was deliberately designed to capture passwords and credit card info, it will probably cost everyone except Microsoft tons of money.
Anybody that works for Microsoft is the last person I would want to read for advice on how to "ship great software on time"!
And this has to do with Microsoft exactly what?
Except for step 6, doesn't this apply to how Linux has done their developement? Or for that matter any software company?
>every piece of software has bugs and issues, regardless of the language you use to describe them.
Very true. I market a software program that I've created, and I don't consider "zero bugs" to be a reasonable goal. What I *do* consider reasonable is that, when a bug occurs, it's appropriately trapped without a complete program crash, the user gets a polite message and some options when applicable, they have a chance to easily report the bug directly to us with relevant details, and most importantly, they have a chance to save their work and exit gracefully. And when I get the bug report, I consider it my duty to handle the complaint with a personal response and in all likelihood an updated version posted within a day or two.
This is quite different from my experiences with programs like Word and Excel, which, when they DO crash, USUALLY do so by instantly quitting, with no chance of recovery or an opportunity to save my work; there is no useful (and privacy-worry-free) way of reporting the bug and little hope that it'll ever be fixed, if even noted. And in my experience, I can kind of count on those programs failing at least once a week under average use, and I know that AutoSave is only marginally useful at protecting me.
Now which would YOU rather have - MS's "zero defect" program, or my less-than-perfect software with graceful error handling and prompt, courteous responses?
--Brandon / Split Infinity Music
for all intents and purposes the drivers are a necessary part of the OS, and as such are a valid point of comparison (if they were exactly identical from OS to OS they wouldn't be, but they aren't and so they are... if that makes any sense :)). Whether or not that is reflects poorly or well on any particular OS is left as an exercise for the reader -- one which certainly won't be answered by anecdotal evidence posted on Slashdot.
HAND.
This is not a list of software development guidelines... Although there are some good things on this list, it is peppered with spin control (3 of the 21 rules are about how to deal with slippage), and rules that protect the hegemony (don't write cross-platform software - wow... what a surprise Microsoft would feel this way).
You want a real list of things software developers should think about? Read Hunt & Thomas' 'The PRagmatic Programmer'
Obviously the Microsoft model is so sucessfull at creating innovative, reliable software that we should all embrace it immediately!
We should run around, hugging our entire team, because the most important thing is the team right? It doesn't matter how good anyone is (in fact, we want to discourage individual brilliance), so long as we have the team.
And making management the cornerstone of the process? Brilliant! Everyone knows that managers are the most intelligent, connected people in the company, how else would they have become managers!
Zero defects means there are still bugs? Excellent! This should work as well as the idea of zero-tolerance rules in public schools.
I think I'm going to get the entire team together and set a milestone of taking a giant shit in the editor, I think we can hit that by the end of the week, but if we have to "slip" the date, we'll make sure that everyone sits down together and eats a couple bowls of bran flakes so we don't miss the new deadline.
Even though our giant shit might be a week late, and be full of bugs (it will certainly be in a matter of days!), we can still consider it zero-defect, on-time and a great piece of software!
second society
Productivity Market: Appleworks, OpenOffice/StarOffice, others?
Very convenient of you to leave out WordPerfect and WP's spreadsheet program. (Forget the name, but, like WP, a lot of professionals swear by it and refuse to give it up for incomplete, can't-do-complicated-functions-or-proper-graphs Excel.) These programs are superior to Word and Excel.
For professional and academic applications, even these are not good enough. Programs like QuarkXPress (pretty much Mac platform only) and Sigmaplot, Mathematica and Maple are used. MS doesn't bother with these markets--too small, and they could never compete because their software will never be up to snuff for the technical market.
Like a good minion, MS MVP's are there.
If it compiles without any errors, then ship it.
So here's one advantage of being a programmer at Microsoft: At least you get dates, even if they are bad ones.
--
More importantly, all bitching about MSFT quality aside, McCarthy was dev/program manager on Visual C++, which is not a poorly-regarded Microsoft product (it's one of the best compiler products on the market). There are extremely successful products --- successful on every axis --- that come out of Microsoft. Visual C++, and McCarthy's book, represents one of them. Microsoft Excel, and Joel on Software, represents another.
Excel may be "extremely successful", but not because it's superior. It was comparable to other spreadsheet programs, and older versions of Excel were pretty easy to use, as it was a Mac-native program built according to Apple's Human Usability Guidelines. (Newer versions are full of annoying popping up Microcrap--you have to turn off all sorts of behavior in 2002 just to use the damn program without interruption.)
Excel achieved market dominance thanks to Microsoft's business strategies. Once MS had market dominance, they stopped developing Excel. Anyone who's used Excel in science or technical applications knows that while it's a decent spreadsheet for easy things, you quite quickly run into its limitations in terms of functions and formulas. Furthermore, its charting/graphing function is simply incomplete. It's as if development was stopped halfway through. Excel users are then forced--like Word users or drivers of jalopies--to arrange their spreadsheets in all sorts of bizarre ways in order to get their graphs to come out properly. Most scientists, in fact, give up and use other programs to make charts and graphs. Heck, a TI graphing calculator can do a better job than Excel.
Excel also stinks at importing and exporting data. Back in 1985 this probably wasn't considered a big deal, but today it becomes a problem. Trying to move data between Excel and Access is excrutiating, never mind non-MS programs. The Excel date format, for example, is a true bitch. Of course MS will never spend one dime to fix these known (for the last 12 years!) problems because they have already achieved market dominance.
(which is essentially what you are arguing with your comparison to Linux) -- is not a logically valid assertion.
(which is what the poster was saying by pointing out that no comparable (in terms of development effort/expenditure/etc.) software is as bad as Windows -- this supports the premise that Methodology1 leads to buggy software) is logically valid.
But I really must applaud your troll -- it contains lots of great red herrings and lots of highly contentious (but ultimately irrelevant) details. Well done, sir!
HAND.
Yes, and I bet the first thing that Linus did before writing the first line of code was have a team meeting and draw out some flow charts... /sigh
i keeed i keeed
Check out my sysadmin blog!
... with 21 rules of thumb?
You know, I wasn't born in a densly populated area, you insensitive clod!
(Or as grandpa used to say, "21 thumbs up!")
The belief in a biblical god is an ignorant one
Will ESR translate this into Halloween XII? Good thing someone reported this leaked document.
>There are many pathologies at play here as well as certain healthy patterns of creative behavior. One pathology is a type of savior complex that cannot be satisfied without blowing every single deadline but the last, and then emerging victoriously with a brilliant piece of work five minutes late. A more healthy pattern is that of the true innovator who is truly designing something great, but who has no personal resources left over for anything but the work at hand. Every ounce of psychological, emotional and intellectual energy is being consumed in the work itself. Teamwork, in this case, is an insignificant factor to a person immersed in this sort of creative experience.
I'll bring your attention to:
"the true innovator who is truly designing something great"
and "Every ounce of psychological, emotional and intellectual energy is being consumed in the work itself"
This is called being in the "zone".
and "Teamwork, in this case, is an insignificant factor to a person immersed in this sort of creative experience."
Exactly.
The key is that when the creative programmer programs, he will program great programs when he alone is the King, God, and Final Arbiter of the program. He is not limited by arbitrary boundaries in the development, only by physical constraints as he understands them.
This is why, ultimately, Open Source software is more brilliant than commercial software (huge generalization of course).
Now, there is a team. Python, Linux, and Perl are not one-man shows. But they have a "dictator for life" person who says "Yay of Nay" to any changes: Guido, Linus and Larry. These guys were the original "guy in a room".
Companies just formalize the creative process into a structure. However, once large sums of money are involved, such companies tend to not give the "Excellent Programmer" the time of day and so he goes off and starts a project on his old debian box.
Of course, with time and tlc, that little project might kick the virtual pants of the industry. But that's after next quarter's earning results, so it is ignored my mgmt.
In fact, due to its worship of Geek, MS is probably the closest, company-wise, to what an open-source keiretsu might look like.
"Piter, too, is dead."
Admittedly, they take slightly different tacks: "Way To Happiness" takes obvious advice cribbed from someplace else and modifies it and then explains how its tenets do not actually prevent you from doing horrible things at Scientology's behest: "Do Not Harm a Person of Good Will", for instance, lets you harm anyone you like as long as you convince yourself that they are not "a Person of Good Will" (i.e., anyone who criticizes Scientology is, quite literally, fair game.) Likewise, "Respect the Religious Beliefs of Others" does not extend to Freezoners.
In contrast, Gristwood's principles are simple and obvious -- but not expressed that way. They are expressed in obscure terms and in metaphors that beg explanation ("Remember the triangle", "Don't go dark") -- I must wonder if the point of expressing them that way is so that they will need clarification, as actual "rules of thumb" typically do not.
If people are to respect the law, perhaps the law should begin by respecting the people.
Yup. Successful at destroying the portablility of C programs.
We are the tech support that say 'NI'
Now go fetch me a radeon or i shall say 'NI' to you...
The Neo-Bohemian Techno-Socialist
1) Buy up a software company.
2) Rebrand their software as Microsoft <descriptive term>
3) Bundle your new software with Windows(tm) under the terms that it costs more to not buy it.
4) Profit!
A bug is a fairly well understood concept: it is a user submitted deviance from the desired behavior.
Obviously few people here understand the meaning of a defect in the softwre development process. It is a deviance from the expected behavior as described in the documentation for the current phase.
The difference is that the documentation for early phases do not have the same level of detail as later phases. Modules aren't fully integrated with each other, so unit test cases must be used. Additional functionality may be added later as well.
The term defect is manager-speak, but it is very useful because it describes something you can measure. It is straightforward to verify that a software project meets a list of criteria to pass a phase gate. It is not possible to determine whether a project is bug-free, because that would take an inordinate amount of test time. This is why real software is never bug-free.
Its referring to developing "Great Software" How does that apply to Microsoft???
When companies start playing games with semantics, especially when it comes to what it's called. There's a very easy way around it:
Caller: "I'm having a problem with my video card."
Tech: "What kind of issues are you experiencing."
Caller: "blah problem blah blah"
Tech: "blah blah yadda yadda issue blah blah"
Caller: "Please be aware that this ISSUE is a real PROBLEM for me."
Then why doesn't MS do it? For any MS fanboy who insists some of their software is great, what about the majority of it? Mediocre maybe?
Get to a known state and stay there.
Instability? FUD? Monopolistic practices? Insecurity? Bloatware? et cetera....
Organize the project around the concept a reaching milestones with zero defects. Zero defects does not mean that the product does not have bugs, or missing functionality; it means that the product achieves the quality level that had been set for that milestone.
Great, so zero defects doesn't mean zero defects, it means some intangible level of acceptable defect. Hm, sounds like a redefinition of language to have the meaning of words fit the state of their software.
Slipping is what happens when information that was unknown becomes less unknown.
Don't not unknow that which is known to be non-unknown knowingly..... Nothing against MS here this guys just sounds like a shmuck.
The product should be built every day, along with all setup scripts and on-line help, in a public place, where QA can conduct appropriate assessment of daily status, and the entire team can observe progress or its lack.
Why that sounds more like a bazaar than a cathedral.
Portability is for canoes...the complexity of multi-platform support is beyond the reach of most development organizations...build your product on the absolute fewest number of platforms possible.
Multi-platform support is beyond the capabilities of MS, not most development platforms. This is exemplefied by Linux, BSD, Gnu software etc.
Enrapture the customers. Most software is a renewal business. Customers buy multiple releases over a relatively long period of time. As a consequence, the market has a deep understanding of your software and its flaws, and your organization and its flaws.
Entrap the customer. They understand your software and its flaws, and your organization and its flaws. Make a token effort to alter the most obvious ways we're screwing the consumer and they'll thank us for only buggering them half the time we were before.
Establish a shared vision.
I'm establishing a vision of a penguin dancing on Bill Gates head. Is it working yet?
Get the team into ship mode.
Tell development the product is being released, ready or not.
Everybody (or nearly everybody) must believe that achieving the milestone is possible.
Ignore whistle blowers, we're releasing.
All members of the team must understand precisely what they must do prior to shipping. All unknowns are factored out.
We don't know if that glaring flaw in our software will be exploited, factor the unknown out.
The goal is an acceptable quality level at ship time.
Noble words, however based on past releases, an acceptable quality level defined by MS is extremely lacking.
Understand the range of quality that is acceptable to your customers.
Will they still buy this steaming pile of...
How many low priority bugs did your product ship with last time? Was it a problem?
Did they take the last steaming pile of...
Are the customers better off with this product including this bug?
Are we better off with the customers money now at the risk of disrupting their lives with our steaming pile of...
Since destabilizing the software is more of a problem than most bugs, be very careful about which bugs you fix.
Don't fix bugs, it might make our software buggy.
This is why we have "ReadMe's" and bug lists.
Releasing buggy software is ok, just let them know after the fact in some obscure reference and our hands are clean of responsibility.
Well, if there were any doubt in my mind left as to why their products could be so horrible, getting an idea of their development method pretty much removes it.
Beware blue cats moving at
How a company acts while facing inward isn't the same thing as how it acts while facing outward.
Microsoft can be honest amongst its developers, make sure they communicate well internally and the code may be simple for them.
Saying software development should be open and honest doesn't always imply that J. Random Goober on the street should be privy to it, or even agree with it.
Mac OS X
Mac OS X
Mac OS X
Mac OS X
Happy? Just be glad I didn't mention AIX or Linux... They could each have some entries in the "Worse than..." list as well.
By the way, my opinion of Microsoft's marketing department is really lousy. I have no idea what the new features in Office 2003 are. I only know of the new features in Windows XP that I can see. I have no idea why I'd want to buy a pocket PC, a tablet PC, or a media center PC. Various Linux distributors have better advertising, but the IBM is just as bad as Microsoft. I know what the technical advantages of Power5 are, but from marketing I just know that Power is the bling-bling architecture. I'm supposed to want to pay money for that??? Likewise, I am familiar with Linux, but IBM ads say Linux is like a child prodigy. Like I'd trust a child prodigy anywhere near my computer.
Anyway, Microsoft's marketing sucks. It's almost completely brand driven, and that actually discourages upgrades.
Variation is the theme restated and elaborated in slightly altered and embroidered ways. Variation is the means by which we intensify the user's comprehension and appreciation of our theme, and leverage his/her growing consciousness in new ways.
I don't think I've ever before seen more words used to say less.
Visual C++, which is not a poorly-regarded Microsoft product
Says who? When I lasted used it, it was a typical Microsoft compiler product - a huge system, with very big manuals, and a phenomenal number of options, memory models, segment types, and strange keywords starting with double underlines. It was a monster. I dumped it.
To actually get things done, I used Turbo Pascal for Windows, and then Delphi.
Portability is for canoes
I thought most of the rules were applicable for the general development community, but this one stuck out like a sore thumb. It sounds too political to be a general development guideline. We all know that the express desire of Microsoft is to tie everything into Windows in order to maximise the usage of their platform. But this often directly contradicts the goals of an application development group.
The reality is that there are many platforms out there, and great software runs wherever the user needs it. This means that multiple platforms are often needed to meet the needs of the user. Some people might argue about the limited functionality of HTML based apps, but in many cases the ubiquity of browser software easily overcomes the limitations of the platform.
Here is an example:
Say that you are writing an HTML widget.
Milestone n states that the widget will display paragraphs (<p> elements) correctly, but says nothing about the widget displaying tables correctly.
When the widget is tested, it displays paragraphs correctly, but does not display tables at all.
The widget is not fully working.
It has bugs.
But, in relation to milestone n, it has zero defects, i.e., it passes all of the tests for milestone n.
While I don't agree with everything in the article, and while I am no fan of Microsoft's, I think that the whole "zero defects" thing has been taken out of context here by several posters.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
Moron.
As compared to the raving Windows fuckwits who've been claiming for years that Linux will never be able to compete with an MS OS, that it'll never 'be ready for the desktop', that MS software is somehow superior because, well, it's produced by MS? Have you forgotten about these stupid little shits?
Linux isn't competing with a MS OS (last check at Google Zeitgeist still shows 1% Linux usage), Linux is NOT ready for the desktop, and for the most part, Microsoft software like Office and Visual Studio is indeed better produced. So what?
There are plenty of assholes on both sides of the spectrum. It's rather clear you'd prefer to pretend that the vast majority of loser fanatics come from the Linux zealot camp, but anyone with half a brain and even the slightest bit of impartiality knows that MS has more than it's share of borg-like twats willing to run to its rescue.
Okay, look, you do realize you're on Slashdot, don't you? A pro-Linux site. There is a HUGE majority of Linux zealots as compared to anyone pro-Windows. If you're going to sit there and tell me Slashdot is some balanced place of 50/50 Windows versus Linux zealots, you're completely lying. Just look at the headlines Slashdot posts on its front page. "Microsoft Violates Human Rights In China." It's ridiculous.
Try getting real. Zealots are assholes BECAUSE THEY'RE ASSHOLES. It doesn't matter what they peddling. Lumping Linux into the mix because that happens to be the bandwagon for one subset of zealots is not only ignorant, it's pathetic.
Where did I lump Linux into the mix? Oh, that's right, I didn't. But you felt that your religion, er, operating system was being threatened and so got all knee-jerk emotion and decided to post, because after all, attacking someone with a different opinion means you have a bigger penis.
Plonk.
Step 1: Drop pants Step 2: Sit on toilet Step 3: Once finished, scoop resultant excrement out and dump into a collection box labeled "Windows", "Office", "Hotmail/MSN" or "IIS" Step 4: Repeat as desired You see, Linux is bound to fail as a viable alternative unless it, too, can follow these steps...
Its all fun and games until someone loses an eye... then its just fun.
You know though, sometimes it wouldn't hurt the programmers to understand the business perspective a little better, or that of the end user. Since these are the people that are going to USE the software, and thus are the ones that are "paying your bills" so to speak. (And yes, sometimes the developer(s) is(are) the user(s). But I'm speaking more generally here.
----- Question authority, but not ours. Hate the man, but we're not him.
One word: poorly.
My writing didn't require a wordy article to get to the kernel (pun intended) of truth. Perhaps the other author is paid per word printed.
"Right now, somewhere in this world, Scott Baio is plowing a woman he doesn't love," - Peter Griffin, *Family Guy*
That's not true. If I write an app for Linux it's not directly portable to Windows. Some of it can be ported easily using Cygwin... but that's just like porting Windows apps and using WINE. In fact with WINE, it doesn't even require recompilation so although it's still incomplete it is compatible at a binary level.
If I write an app for Linux, it's not necessarily directly portable to OpenBSD... although that's easier than a port to Windows as they're both UNIX-like OSes.
Try learning the most basic definitions of quality control before spouting this kind of crap.
A defect is a failure to conform to requirements *PERIOD*
Bugs are catagorized into severity levels. Quality specification say things like:
R1.1) A release candidate shall not contain any Sev-1 bugs
R1.2) A release candidate shall not contain more than 5 Sev-2 bugs
So, in our example, a product with less than 5 Sev-2 bugs conforms to the requirements.
A product that conforms to all of the requirements has ZERO DEFECTS.
Get It?
BTW, don't you ever get tired of spreading FUD for Microsoft? Actually, I think you enjoy it. Do you enjoy beating your wife?
Congratulations, bonch, your witty rejoinder of anyone who write the two characters M and $ next to each other has solidified you as a scholar and a gentleman. It has raised the intellectual level of your post beyond mere quip to insightful social commentary on the state of our world. You have therefore been chosen to receive the Official Douchebag Trophy! On its side are enscribed the words, "Trolling like it's still 1998," to point out that pointing out people who use terms like "M$" got old in 1998. We are happy to give you this wonderful award, and congratulate you again.
Don't call us, we'll call you.
A defect is a failure to conform to requirements *PERIOD*
Bugs are catagorized into severity levels. Quality specification say things like:
R1.1) A release candidate shall not contain any Sev-1 bugs
R1.2) A release candidate shall not contain more than 5 Sev-2 bugs
So, in our example, a product with less than 5 Sev-2 bugs conforms to the requirements.
A product that conforms to all of the requirements has ZERO DEFECTS.
We have all learned these principles in our college classes. They all sound good and resonate with us as what we *should* do. But the real question is, do they result in good software delivered on time, with good quality?
In order to create a list of rules to deliver good quality software on time, someone would need to have experience with or interview someone that has achieved those results.
Microsoft does not release quality products on schedule. They habitually slip their products by years and release their products way before they have been quality verified.
They do indeed have some quality products, but they are a long time coming and they usually are preceded by many versions of inferior quality first.
This list is similar to the business guru books full of the latest buzz rules. And then there is Peter Drucker, who actually studies the REAL successes and writes what THEY do. Those are the REAL rules.
Great conclusion you have there. Sure, we'll compare to their corprate peers, then not make a statement about what the group comprises which means 1) You talked yourself into a corner and decided not to look up/think about anything to back things up 2) You're making a poorly executed "microsoft is always a monopoly" joke. At the least next time make a list so people get where it's going, instead of thinking maybe point #1 is what happened.
Slashdot: Where anecdotes and generalizations can be freely substituted for facts, logic, or intelligence
In QES (the quality system developed by IBM), a defect is a failure to conform to requirements *PERIOD*
Bugs are catagorized into severity levels. Quality specification say things like:
R1.1) A release candidate shall not contain any Sev-1 bugs
R1.2) A release candidate shall not contain more than 5 Sev-2 bugs
So, in our example, a product with less than 5 Sev-2 bugs conforms to the requirements.
A product that conforms to all of the requirements has ZERO DEFECTS.
iD's never stated a ship date. Activision's a different matter entirely.
:-/ No BF, no Painkiller, and UT makes my eyes bleed.
Personally, I just want the damned game to come OUT. iD games are effectively IT for Mac FPS.
In the software shop where I worked, we had an NT box that crashed *daily* if not more. We eventually replaced it with a Linux box and never had any more crashing problems. So while NT boxes *can* be stable, I'd say it's more the exception than the rule (which seems to be the reverse relation WRT to Linux).
This is true even with 1.4. I was really astounded by this software. You're right; it appears native.
grammar-lesson free since 1999. (rescinded - 2005)
Thats not to say that MySQL doesn't do the job in many situations or that it is bad software, but calling it a full featured SQL server is sort of funny. Also comparing performance of MySQL to MS SQL in enterprise applications would be interesting. I don't know the result but I think that MS SQL is still "fastest" in the world depending on just how you rate it.
"You can now flame me, I am full of love,"
All the evidence is that Microsoft have skilled developers who know how to build high-quality software. They have known how to build solid code for a good decade now. Yet they still don't actually build high-quality software. Why not?
Similarly, all the evidence is that Microsoft have a massive well-funded research department filled with smart and inventive people. Yet I can't think of a single innovation Microsoft has actually rolled out in shipping product, that hadn't been done before by someone else, and usually done better.
To me, the question of why Microsoft is institutionally unable to harness its clueful employees is much more interesting than what those clueful employees have to say. It must be pretty frustrating for the smart engineers at Microsoft, in fact, seeing their work ignored or screwed up. Still, I guess the piles of cash make up for it.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
rather than deeply.
The Microsoft interview style is to ask the interviewee a constant stream of white board programming problems and throught puzzles. While this selects people with a certain level of intelligence, it also selects people who can think rapidly "on their feet".
Perhaps the end result is to select a homogenious population of "Softies" think fast, settle on an approach and then hack it into code. Where a better approach to product development might be to think about the design, think about some alternatives, discuss the design and then implement it.
Many people agree that Microsoft software evolves once it has been released. The common example being a first product that is inadequate, buggy and slow, eventually evolving into something that becomes popular. Perhaps this is a result of a culture of programmers who believe they are very smart (after all, they survived the Microsoft interview), think fast and then entomb their initial half-baked design in software.
Now I understand more about why Microsofts software products are relative crap compared with most any of the software corporations of note out there. They've missed one of the most important items (I'd put it as number 1), and I think it could very well be intentional:
1. Learn from those who have gone before you-- do not operate in a vacuum. This is not the first time such a project has come about, nor the first time such a product has been developed. Remember that if you ignore the mistakes of the past, you are very likely to repeat them.
Note that there are NO references to any historicity of the problems in any way-- its clear the entire list of development dos and don'ts here were crafted from scratch completely within the information vacuum of Microsoft. It is as if it were the first time such things have ever been done. Of course, by ignoring other similar developments, I suppose you can then say you are "innovating," but only from ignorance-- it is as "innovating" for someone kept in isolation to invent the wheel as it was for the original cave-man(?) to do it I suppose, but what does it really mean to be such an innovator in a world where everyone else have been travelling on wheels for centuries?
If it compiles, ship it?
A more healthy pattern is that of the true innovator who is truly designing something great, but who has no personal resources left over for anything but the work at hand. Every ounce of psychological, emotional and intellectual energy is being consumed in the work itself. Teamwork, in this case, is an insignificant factor to a person immersed in this sort of creative experience.
That's healthy? I prefer not having a job over working for assholes like that. No hobbies, no home life, not a single psychological or emotional ounce left? The free software model, where the most programmers devote less than five hours a week to their projects (see page 3) has been far more productive.
Microsoft would like every company to be so soul sucking. If they were, it would be much harder for people to co-operate with each other and make things work. Hopefully, most companies do not treat their employees like sacrificial animals and realize that people work for a living rather than living to work.
Friends don't help friends install M$ junk.
A company that violates it's duty to it's customers and share holders is sure to violate it's own employees. It's all part of believing that it's OK to violate people. Microsoft employees, typically, are shareholders and customers. Can you expect to be treated any better?
Friends don't help friends install M$ junk.
I wish I had chimed in earlier. I'm an aspiring mathematician, not an engineer but I don't have an issue with the term 'zero-defect'. Engineering is all about tolerances and software engineering is no different. The highly mathematical nature of programming (as opposed to development) tends to obscure this fact. When an engineer designs a bridge they're not concerned about perfection, only how it will perform under a constrained set of conditions. For example, consider the math: the sets of memory locations and registers are finite and therefore pointer arithmetic (the operation of succession) is not closed hence buffer overflows are always theoretically possible on the hardware level. Some languages (C) unfortunately encourage us to forget this, and others (Java, and the .NETs) try to help out by at least simulating an environment in which we have infinite sets of memory (or in purer mathematical terms, pointer arithmetic is closed). The point is, as long as you're coding to the bare metal (and at some point you must) you'll always have the chance of at least this kind of 'defect'. At some point you need to be pragmatic (somewhat antithetical to pure mathematics) and decide when it is good enough: i.e. how many possible inputs should you test and how much peer review do you need? I personally would prefer to see software constructed in the same way as a mathematical proof (especially the peer review part which is a good argument for open source) but I also recognize that this is not compatible with all business models.
After a closer look, this really must be a gag. I mean, is it really possible they are that clueless? And some of the items seem just a little too self-parodying.
Reread the paragraph "Don't go dark." This one's got to be the most obfuscated in the bunch-- in other words, the darkest of the bunch...
Gotta be a gag, I'm tellin ya...
...every piece of software has bugs and issues, regardless of the language you use to describe them...
True, there are bugs and issues which dont' bother me as long they are not security flaws.
And as story of qmail shows you can write a software without security flaws - in its seven years of existence, Qmail has never had a security flaw!
This is definition of GREAT SOFTWARE to me.
-- All Gods were immortal.
-- S. Lem
Friends don't help friends install M$ junk.
If it is overpriced, then how come you can get a DELL or HP pc with Windows XP for only $20.00 over the cost with Linux?
Their end user software is low priced and high value - yes you can get Windows XP home + Works for $150 or less.
That gets you an OS, word processor, spreadsheet, low end dbms, etc.
Remember that my original point, apropos this whole Slashdot article, is that Microsoft does make highly-regarded products, and Visual Studio is definitely one of them.
I strongly disagree. Visual Studio is highly tailored to a specific approach to application development that suits Microsoft, in which developers use the Windows API and pre-compiled components. Bill Gates knows how things could have been so much better - in the mid 1980s he saw real object-oriented designs and interactive development systems when he was introduced to Smalltalk. He saw how developers could be free to write extensions to the IDE, how running applications could be interrupted, inspected, and new methods added. He even said 'this is the future'. A few years later, he figured out how such a system could be sufficiently crippled as to make the most money for Microsoft and released... Visual Basic.
Visual Studio is a crippled version of what it should have been.
I'm posting this so that you (the moderator) have some context to consider twitter and not mod him up whenever he posts his filler preformatted rants about installing Knoppix or whatever that unfortunately get him karma every single time and allow him to continue posting his trademark toxic crap (read on) day in and day out. You may consider this a troll - I consider it community service. And I ain't kidding.
If you're a /. subscriber, I invite you to look through some of his posting history. I guarantee that you'll be hard pressed to find someone that is more "out there" than twitter. You'll also probably notice he's got quite an AC following. Don't just read his posts, make sure you go through the replies.
To get an idea of what I'm talking about, check this post out. I mean, this is an article about email disclaimers, right? The parent of the post is complaining about the ads in the linked page and so on, and twitter actually goes off on a rant to blame it on Microsoft and recommend Lynx. WTF?
Here's another. In this post twitter not only calls the OP a troll but attempts to "tell it like it is" while making some vague argument about "GNU". Yes, if you're confused, you're not alone. The reply (modded +4) proceeds to simply destroy his bogus argument. You will notice he did not reply. This is what some people call "drive-by advocacy". A sort of I'll just leave you with my thoughts here and move on to the next flamebait kind of deal. In fact, he almost never replies because he knows that his fanatical arguments simply do not hold up to any sort of discussion. It's not that he's chosen the wrong cause - he's just going at it in a completely wrong way.
More? Just read though this post and the subsequent replies. I guess this stands on its own. Or these two. Or this one.
Still not convinced? This is what twitter considers "humour" while going about his daily "M$" routine.
More? Bad spelling in astounding conspiracy theories, more offtopic FUD and uninformed "I'm right, look at me" rants, promptly proven wrong. Worse even, twitter wants to be RMS, apparently (that first one is a winner). I mean,
Yep, they've come a long way, pardner.
Unfortunately, I can't find any mention on A-W's web site.
Half.com says 'June 2005,' and Amazon says 'February 2004,' which seems unlikely... :-)
Still, if it's useful I suppose there's no point in waiting a year for the new edition...
The widget is not fully working. It has bugs. But, in relation to milestone n, it has zero defects, i.e., it passes all of the tests for milestone n.
No, in the relation between the widget and milestone n, you get "ERROR: Variables are not of the same type."
Milestone = Bureacracy. Milestone has been completed.
The product, on the otherhand, is unfinished.
What's actually defective is the way you're thinking about it.
Of course, we all know how difficult it is to write a complete set of tests. Particularly if all error cases must be included. The last time I had that particular pleasure was for a relatively simple (compared to an HTML widget) piece of real-time software. The documentation ended up going on for dozens of pages about the conditions that the internal data structures and a received message must satisfy in order to be consistent (inconsistent messages were discarded and reported). The section specifying what the component actually did when it received a consistent message was much smaller.
These rules make windoze suck more as a OS no wonder it is so buggy
That's still trimming off a good portion of the whole in order to force-fit it to the argument. If the widget in question doesn't render as expected in the presence of tables, one of two things is at fault: The developer, for not understanding the spec (see the article's beginning section). Or, the specification, for being ambiguous. Either way something is broken, and it very rarely is the specification.
I'm losing my patience for this type of weasel-y behavior from developers. It would not fly in the manufacturing industry. Software developers break the standard (either on purpose or out of ignorance), and then send PR people on a world-wide, media-weasel word-mincing tour in the hope that if they seriously damage the public's understanding of the issue, the public will eventually abandon its quest for answers.
Fred
"A fool and his freedom are soon parted"
-RMS
Well that's kind of my point - it's portable to... other open platforms.
It may not be easy, but it's both legally and technically possible, and in most cases fairly easy. Witness all the apps that have been ported to OS X since it has an open core and supports the X protocol. Open standards=open platforms=portability.
Of course there will be some counterexamples, but closed platforms are by definition barriers to portability.
microsoftword.mp3 - it doesn't care that they're not words...
How long does it take from the announcement of an exploit on (say) BugTraq until you get a fix through Windows Update?
I've seen it be a matter of hours from exploit announcement to 'emerge sync && emerge -uD world' patching.
I've also seen it take a matter of months for known exploits in Internet Explorer to get patched.
Also, I've had Windows 2000 Pro crash for me (solid lockup) before I'm even done getting the Windows updates. It continued to crash later.
The Nvidia-enabled X server crashes every now and then, when I'm playing UT2004. This is less than once a day, and since I usually have one X server dedicated to games, nothing critical dies. I'm running reiser4 as a filesystem, which is not released and comes with a big fat warning of how experimental it is, and have had no full system crashes, ever, that were not caused by a forkbomb of my own design.
The EULA is important, but it is offtopic. But for the record, I don't use IBM or Apple, either. And seriously, if you don't care about EULAs, let me write one up for you for this custom KNOPPIX disk I made. Go try it out and watch it turn over your bank accounts to me...
Many people are still stuck with 98, it's true, and 2000/XP have gotten a lot better. But I believe I've heard of machines THAT ARE STILL RUNNING on Linux kernel 2.2. That's several years of solid uptime on an OS that is at least as outdated as Windows 98.
I can run Linux without a firewall or antivirus naked on the Internet, and it works fine. I can open any email I want, but in order to catch a virus from it, I have to save the attachment to disk, change the permissions on it, and run it manually -- probably under Wine, since Linux doesn't have that many viruses yet. I've seen Windows 2000 machines infected within SECONDS of being plugged in to a college network, and Outlook Express + IE = viruses + trojans.
And that's only the security advantages. Linux has always booted up faster for me, run faster, and made me more productive than anything else -- including the new PowerMacs.
Familiarity breeds contempt. Make sure you're not a zealot before you call other people by that name.
Don't thank God, thank a doctor!
With a robust and highly modular application you can build as many features as you want into it. Each 'feature' should be as self-contained as possible. Global variables and objects are for amateurs (and me if I'm lazy). Like, if you ever see something like this x = myObject.someObject.somethingElse.setX(temp), then you know there's going to be trouble down the road.
But is there anyone who would actually listen to development advice from Microsoft?
Seriously they are infamous for turning out the worst software ever produced, they fail on every major checkpoint.
Simplified interface, fail, menus are cluttered and unintuitive.
Security, fail, their record speaks for itself
Stability, again fail, again their record speaks for itself.
Performance, fail. MOST competing products run faster than the Microsoft equivalent not one or two, not somebody beats them, almost everybody beats them on almost every piece of software.
They may finish a project which is more than some can say, but that is about all they have going for them and it's arguable if they've ever TRULY finished a project.
Here's how it works in the corporate world:
Release early - with a label that says "This software is not finished, but we guarentee it will be in a year and you can download the patch."
Release early #2 - hire beta testers.
Release often - patches, and for that matter, "release rarely" doesn't work -- remember the IE exploit that waited months for a patch?
Listen to your customers - Works in open source -- subscribe to reiserfs-list@namesys.com if you don't believe me. If only they did that in the real world.... see above IE bug.
If you did "listen", you'd do 'rmmod nvidia; modprobe nvidia' after the upgrade, and your brand new nVidia drivers would be installed -- no recompile, no reboot.
Don't know much about Samba or Active Directory, but I will say this -- the only reason I ever run Samba is when I need to copy a file to a Windows machine. Otherwise, I control things with cfengine, ssh + pki, and so on. Yes, I even control my Windows boxes with ssh + cygwin.
And if I wanted to do something like an NT domain, I'd run Kerberos.
"Open source "works", but not all of the time, and not always how you want it to."
Did anyone ever claim it did? Does closed source do that? Shit, does anything, anywhere, ever work all of the time, exactly how you want it to? Not even sex does that!
Don't thank God, thank a doctor!
Ever notice that people who would say "Dilbert is for losers" are the losers most often featured in Dilbert? Everyone else just doesn't get it.
And the question is: Why is security a problem?
They're not just other open platforms. They're all UNIX-like, which is what makes it easy. They could just as easily be ported to Solaris, etc. Didn't they open BeOS - how easy would a port to that be?
1. It is possible to program a bug-free program.
2. Security is not an inherent issue with computing.
3. A program that does not work is not finished
4. Computers are made of 0's and 1's.
5. CODECs are temporary in the computer timeline.
6. x = 2 * y means something different in programming than in math.
any old-schoolers care to add some more?
There are known knowns.
These are things we know that we know.
There are known unknowns.
That is to say, there are things that we know we don't know.
But there are also unknown unknowns.
There are things we don't know we don't know.
Makes perfect sense now.
Vista:XPSP2::ME:98SE
Well, here's a few:
http://www.newbreedsoftware.com/beos/
Granted I think these were all ported to Windows as well, but that's because... they used SDL (an open platform). Hurray!
microsoftword.mp3 - it doesn't care that they're not words...
Umm, when exactly is 12:00 in the afternoon? Or is that just a rounding problem?
Sorry. Late nights make me grumpy and pedantic.
Cogito, ergo sig.
Kinda late in the post, but here's' how MS makes their software.
1. Take a million monkeys and put them in fron of a keyboard.
2. Try to build every evening.
3. First successful build ships.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Beware of a guy in a room:
As an employee, I'd prefer to have some resources left over for, oh, let's say, trivia - my real life, for example. Staff with no life don't tend to last long.When Slipping, Don't Fall In a context of extreme openness about failures, this makes my Subject: line a lie
"Portability is for Canoes" says a lot about the Microsoft attitude.
In the "Ship mode" section, he comments:
Is this some strange usage of the phrase "fire-drill" I was not previously aware of, or he he seriously suggesting that shipping a piece of software on time is more important than staff safety?In the same section:
This seems to be the principle goal in the design phase of good software; making this the principle only in the final stage may explain the state of some Microsoft software.Overall, this 21-points and the MSF itself look like very realistic documents, learned from the lessons a huge company such as MS have had the chance to learn. Certainly not to be dismissed just because of the source.
Author, Shell Scripting : Expert Re
21. Get the team into ship mode.
There is a moment on every development project when it is ideal for a team to enter ship-mode. Ship mode is a high performance period characterized by efficiency and determination. It is a period of flow. Before a team can enter ship mode, several pre-requisites must be satisfied.
1. Longhorn. New XML file system.
2. "Oh FUKC!"
3. "We'll never get this out. How about 'Windows XP2 deluxe turbo +++'?"
4. "Yay!!!"
5. Call Marketing.
...I shall politely say, were somewhat less than successful...
It is not polite to belittle the effort like that, if you want polite, try other than successful. Avoid words like less and more, as you could offend someone with size issues.
Huh... I always thought it was the 1000 monkeys typing randomly at 1000 keyboards method. Could of fooled me.
That only works for free software
What about apple? The first version of OS X was fairly unfinished, 10.1 was a little better but still not quite there; it wasn't until 10.2 where they got something good, finally 10.3 was really polished. Each version got faster and had more features.
Same thing with Safari.
I definitely believe that release early, release often is for everyone, open or closed software. You just have to make it easy for people to upgrade and (try at least) to not break anything between upgrades.
There was no expectation for tables to render at all for milestone n.
Therefore, it was not a defect that tables didn't render at milestone n.
Presumably, at some milestone n + i for some i > 0, the widget would be expected to render tables properly.
At that point, if they didn't, then that would be a defect.
But not until then.This has nothing to do with internal milestones.
We're not talking finished product here.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
If someone happens to put a table in a test for milestone n (in my example), and tables are not expected to render properly by milestone n, then the test is defective, even though, eventually, the widget should render tables properly.
There is a difference between testing at intermediate milestones and final testing.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
You mean a product that hasn't reached its final milestone is unfinished? Who would have thought it?
I'm sure the time you spend arguing over which word to use gets your problem solved much quicker.
What variables?
What are you talking about?That's true.
But this has nothing to do with the finished product.
It has to do with product milestones, all of which but the last are intermediate.
Since some of you seem to be having problems with my example, let me go into it in more detail.
Let's assume that by milestone 3, the widget should be able to parse HTML and produce errors for invalid HTML.
There is no requirement at this point for anything to render at all.
So the widget has to accept <p> and <table> tags and reject, say <blingbling> tags, but doesn't have to render anything yet.
Therefore, the test suite for milestone 3 has to include <p> and <table> tags.
Now, let's assume that the widget does accept HTML that includes these tags, but renders nothing.
Then, in relation to milestone 3, the widget is performing as expected, and thus has zero (known) defects, even though it has problems (i.e., not rendering) that must be addressed later.
Now, say that milestone 4 requires the widget to render <p> tags, but says nothing about rendering <table> tags.
If the widget renders <p> tags correctly, but does not render <table> tags at all, it still passes tests for milestone 4, and thus has zero (known) defects with respect to milestone 4.
OK, so what if the widget does render <table> tags by milestone 4, but renders them incorrectly (formatted badly, in the wrong font, etc.)?
Since there is no requirement for the widget to properly render <table> tags by milestone 4, then bad or "buggy" output is irrelevant, and the widget still has zero (known) defects as far as milestone 4 is concerned, even though there is an obvious bug with how it renders tables, and that bug will have to be fixed somewhere down the line (before passing the milestone that does require the widget to render tables correctly).
That is what I believe that the author of the article meant when he wrote that a program can be buggy, but still have zero defects in relation to a specific milestone.Personal attacks are a sign of immaturity.
(That's a joke (kind of), but I hope that you get my point.)
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
Linux is a kernel, and ontop of it lies the GNU operating system which is composed of lots of littel 3rd party tools all based around the bsd/unix setup.
Now, redhat as a whole can be called an OS, or mandrake etc....
There is nothing stopping Redhat or Suse from porting their 'OS' to freebsd or netbsd, or even darwin and it still looking like former. It wont use linux kernel, but it will look the same, but you cannot call it linux.
So what is linux? at the core , nothing more than the kernel/driver layer.
Except MS has merged the kernel/driver/graphic/desktop/filemanagement layers all into ONE package which they 100% control like Apple too.
Liberty freedom are no1, not dicks in suits.
Wow, that's harsh.
I suppose that the money that Bill donates to medical research (read this) would not count for anything...
Do you really think Windows is used for mission-critical hardware environments?
So you do not have to lower yourself to his level
He is a complete moron who it certainly appears has never worked developing software, and certainly testing software, in his (her) life.
There are separate medical dictionaries and separate law dictionaries, and as a matter of fact there are many other dictionaries for different professions. Why? Because a word can mean something a lot more precise if used in a certain profession than if used in general use.
If a user reports a fault, that does not necessarily mean the software is faulty. It may be due to the user not knowing how to use the software. It may be due to the software not performing how the user had expected (so is OO.org faulty because a user expects it to behave like MS Office?).
But of course, M$ is the suxor! Linux is the roxor! I am so 1337 because I emerge world every day. Anything Micro$loth does is stupid and Open Source projects always follow perfect software engineering methodology.
I find it kind of interesting that #12 is "Portability is for Canoes". He basically goes on about how you shouldn't worry about portability, because it adds too much overhead. He also goes on to mention that only large companies can handle developing software for more than one platform.
Kind of figures, considering the guy is a Microsoft employee.
Is this blog entry a joke? It's overly vague and without substance.
Are there Banana trees in the silicon valley?
Webmaster of Infoweb
The fact that it runs on .NET is less a problem than just its behavior. It's doing more, all the time (the live context-sensitive help is a major CPU sucker).
This isn't anything new, by the way... it's been heading down this road since Visual C++ 5. IMHO, Visual C++ 4.2 was the last "lean" IDE--5 and 6 were a major slowdown.
When the software causes so many hours of lost time, lost wages, lost data, and corrupt data as the Windows family of "operating systems", the vendor should be paying you to take the disks off their hands.
I do not fail; I succeed at finding out what does not work.
You Have Been Trolled. :-)
You Have Lost.
Have A Nice Day.
I wrote my most recent, decent-sized project ... with built-in updates so that with almost no effort whatsoever, I can issue updates and patches and the program will notice, when online, that these new patches exist and offer to download them!
So are you writing viruses? Or anti-virus programs?
The only good thing about viruses is that they have advanced the state-of-the-art for self-updating programs. All the effort Microsoft has put into WindowsUpdate would not have been done if viruses were not taking advantage of security holes. That is a good thing because if MS had put that effort into securing their OSes, there would be less incentive for people to switch.
I spend my life entertaining my brain.
As to why you weren't modded up.
It's nice to have someone who actually replies with relevant points rather than spouting the all-too-familiar zealot mantra.
I agree that there are zealots on both sides, but the original discussion was about Microsoft's management practices. While this is a slightly offtopic for this thread, I would suggest that Microsoft is still no shining example of project management, because as a whole, they haven't done any better (and in many cases, much worse) than their peers. It seems that people have begun to equate financial success with genius, a rather unfortunate circumstance for those of us who actually do know how to bring a project in on time and to standard. (Though I'll freely admit I'm not one of them...)
The society for a thought-free internet welcomes you.
Ok I know what you're saying. The widget has zero defects if it does what it is expected to do. In your example though, milestone 3 is not free from defects since it is the job of that particular widget to reject invalid HTML. Rendering nothing != rejecting invalid HTML.
... go work for Microsoft.
Additionally it's my opinion that widgets must not be able to produce any internal 'bugs' or errors of any sort if they have zero defects.
That's not too much to ask for. If it is, well
That variable thing was because you are totally mixing up in my mind what a milestone and what a widget is. The milestone is free from defects so the widget is, while still defective, free from defects? The milestone is not a program, it is a project thingee on a piece of paper--it can't be free from defects. The widget on the other hand, can. You could say the task required of the widget, as defined by the milestone for that widget, has been completed. Unless again I am confused as to what a widget is, "free from defects" is completely obtuse, and it's no wonder I'm confused (and to me, that means it's no wonder shiatty software gets made).
Rule (1): copy whatever Apple did 5 years ago that almost killed the company, but cheaper and uglier.
--
make install -not war
Good luck bringing IIS into the argument against Apache. 63%+ of market share and it still kicks IIS hard. Claim the bundled IIS with the Windows OS all you want but you still pay for it (it's just hidden cost, commercial vendors can do that sort of thing, live with it).
For the less security patches/bugs and it sees radically more use. IIS wouldn't look so bad if Apache was commercial but since it's open source IIS is in a very sad state of comparison (i.e. none due to it's serious commercial backing by one of the largest software companies ever!). Next thing you'll say is that Apache somehow copied IIS without the flaws, since you appear to be a Microsoft sider.