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
Enrapture the customers
Shouldn't that be shrink-wrapture the customers?!
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.
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"?
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.
When was the last time that a certain game company released their software on time? Or for that matter, a lot of game companies these days?
Hmmm.
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.
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.
that's the highest he could count with his shoes off and pants down
try { do() || do_not(); } catch (JediException err) { yoda(err); }
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/
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.
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
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.
#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.
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.
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
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.
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.
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.
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
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.
You're right to an extent, but think of it this way. Typically, MS programmers are good at what they do. It's doing what they're told to do that can be a problem. Or worse yet, teams not communicating with other teams (through their team lead/project manager/development manager) that can cause problems. Even worse than that, it can be QA departments that aren't fully testing or are not communicating all known issues back to development teams.
All of that can actually be attributed to poor management. Not necessarily in the sense of management not understanding the process, but leaning more toward the "ship the products for $$ sake" rather than "build better products for less profit, but better reuptation" business model.
MS is in the business to make money. So far that's worked out quite well for them, regardless of the quality of their products. OSS has done a fairly nice job of forcing MS slightly into the latter business model, but as we all know, not far enough. It may never happen that MS fully embraces the idea of building better products for less $$.
As a programmer with 13 years of professional experience, I can attest to the fact that an app with no defects/bugs/issues/ on the first compile would be a miracle. Programmers have trouble thinking like users and consequently have trouble imagining every possible way of breaking their app.
That being said, I firmly think that most of MS's problems with software have much more to do with management than with the developers themselves.
some developers from MS discuss how they deal with damage control on a daily basis. I think that would drum up some interest.
Typically, that's management's problem, and if it never makes it back to the developers, they continue coding on what they're told to code on.
My $0.02 anyway.
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
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.
-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.
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.
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.
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.
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 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.
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.
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.
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...
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.
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
"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".
Except for step 6, doesn't this apply to how Linux has done their developement? Or for that matter any software company?
So here's one advantage of being a programmer at Microsoft: At least you get dates, even if they are bad ones.
--
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
Actually it was an oversight that I left it out. I haven't used WP in years but many of the professors around my work use it because it handles Turabian formatting much better than anything else. And the other list of applicated further illustrates the point I wanted to make, MS is not the best player in the game and really the only thin that keeps them where they are is general ignorance and monopolistic market dominance.
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
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.
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
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
BTW, don't you ever get tired of spreading FUD for Microsoft? Actually, I think you enjoy it. Do you enjoy beating your wife?
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.
Linux is NOT ready for the desktop
Yada yada. Guess you're one of the twats I was talking about. Cue Billy G-worshipper rant on just how 'unready' Linux is. Not that we haven't heard this bullshit argument a THOUSAND TIMES already, but hey - when does that deter a zealot?
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.
Hey there Homer, try 'Reading Comprehension 101' and 'How to Present a Strawman Without Looking Like An Amateur 103'. Which one will be most helpful depends on whether you're just plain stupid or making a pathetic attempt at being deceptive.
Where did I lump Linux into the mix? Oh, that's right, I didn't.
Oh, that's right - you did. Linux zealots is what your whole post was about. You aren't related to the late President Reagan, are you?
But you felt that your religion
If Linux were my religion I'd never admit that there are plenty of assholes and zealots on both sides of the fence. Here's a quarter, go buy yourself a clue.
Oh, and my penis is bigger than yours no matter what I post on Slashdot. Zealots, as a rule, have tiny peckers. It explains a lot, when you think about it.
Max
My god carries a hammer. Your god died nailed to a tree. Any questions?
If it compiles, ship it?
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.
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
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.