“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”, says David Gristwood.
21 Rules of Thumb – How Microsoft develops its Software
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Well, like Anonymous said above, maybe profit may be the main goal of MS as a company, and the fine ideals always differ from real life…
But the 21 rules of thumb listed here by David Gristwood are actually quite good and worth studying by anyone. Some rules or ideas presented here would be useful for many open source projects too, in order to have a better focus in those projects.
A radical “bazaar” model of loose, rather non-organized cooperation and change of ideas is useful but it works only sometimes. The more complicated and demanding a project is (like when building a cathedral, if we use Raymond’s terms), the more useful it is to have a well organized development model with clear guidelines etc.
Sorry for the Slashdotism… I couldn’t resist it! Feel free to mod down or whatever.
I think that a healthy respect for portability can prune some scope creep. If they had to make Outlook run against more than Win32s, might it not be such a … ?
“A radical “bazaar” model of loose, rather non-organized cooperation and change of ideas is useful but it works only sometimes”
you misunderstand the concept of the colloborative development model. its not any less disorganised than closed office to office models. look at debian policies, gnome release schedules or python pep’s for example of how cooperatively organised these can be
He left out the most important rule of all; embrace reality. There is that perfect moment in every project, like the eye of the storm, dead calm and with crystal clarity that only hindsight can bring, ahh the sweetest, shhhhh, you can hear somewhere at this very moment, reality is rearing it’s ugly head.
The sooner it intrudes the better, invite it to every meeting. Hold it out front like a shield.
Yeah, I think they are quite useful.
At least just when I started reading he wrote about the issue that let my last project fail … there must be some grain of truth in it … hehe
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 3:18 PM Peter da Silva
Reading this helps me understand many of the frustrating limitations of Microsoft software out in the real world. For example:
Portability is for canoes (and system software). “Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible.”
Of course, for people outside Microsoft applications like Office and Internet Explorer *are* system software. To Microsoft, they’re the product, and portability is something to be avoided, but to us they’re what we build our own software on: how do *we* build great software for the Microsoft platform if Microsoft’s developers refuse the same support they demand of their software division?
Remember the chant… “Developers, developers, developers?” We’re all developers, and even if all one of my users is developing is a web page they don’t want to have to fight Microsoft to make it work where *they* need it
Then i see someone posting about Outlook not Win32 only. Please consider MSIE, while it was trying to compete on Netscape, was available for many Unices including Solaris, HP-UX, MacOS and others. It was for free (beer). After MSIE and Windows were the defacto standard these ports were stopped although MacOS was one of the latest port available.
While in a huge hierarchy which falls under one name opinions may differ, doesn’t this fully contradict this portability point? Or did Microsoft really liked it when they had to (pay others to) port MSIE over?
Plus, isn’t this what Java/.NET is partly about: Release once, run everywhere? Or was .NET meant to be only “portable” on the Windows platform?
If this is an indication of the “quality” of programmers MS hires, it’s not surprising they have as many problems as they do. Most of the rules weren’t rules and had nothing to do with developing software. Two of the rules were VERY telling:
12. Portability is for canoes.
13. Enrapture the customers.
Rule 12 restates MS’s goal to keep their monopoly. Rule 13 shows that marketing is more important that development.
However, Microsoft does not have a history of successfully shipping products on time, but rather of successfully slipping products most of the time.
0. Steal intellectual property from other companies, incorporate into Windows, and then pay off government to make sure open source movement dies.
…the dark and a guy in a room.
In other words, beware of the guy who can get the job done and doesn’t want the project held up by less advanced (i.e. less intelligent, less experienced) developers or project managers quibbling about the non-issues in his project.
In other words, beware of the guy who can get the job done and doesn’t want the project held up by less advanced (i.e. less intelligent, less experienced) developers or project managers quibbling about the non-issues in his project.
Well, you can never sit completely by yourself, but in general this is correct. Ultimately, you need some people who can sit there, work hard and get the job done but you do need to come out and see what is happening when necessary. To get work done, you have to go dark from time to time. You only get that from experienced, good people who know what they are doing. Even many, supposedly experienced people in positions of authority cannot do that at all.
A smaller effort is almost always more desirable than a larger one
Um ok.
Interesting the only thing Microsoft is concerned is that the Builds continue to work from day to day.
NOTHING on testing or scalibility.
Nothing on Design or Code review.
This is clearly why their software is sub-par.
Great is a relative term. I wonder just who do they compare themselves with to call their software GREAT. The only company I’ve seen deliver worse software was MicroFocus Cobol, and that was 10 years ago, so even thay may now be writing better software then Microsoft.
Maybe they mean a feature checklist, where the strength of 35,000 lousy or lazy programmers can effectively compete.
But, the saddest thing is nothing has changed and from this article it seems nothing will change.
12. Portability is for canoes.
Rule 12 restates MS’s goal to keep their monopoly.
I disagree. Striving for portability can increase code complexity (which is liable to introduce errors) and may require you to not use certain features that are not portable (thus requiring reinvention of the wheel and potentially a lower quality product).
Portability is only worth engineering in if:
a) The product requires portability as a major feature;
or
b) The product may require portability in the future.
Obviously, portability is of more interest with off-the-shelf packages, where you want to widen your target audience, but not if the cost of portability outweighs the potential increase in market.
Where I work, we produce bespoke software packages for various companies. The quotes and specs list a target platform which the product will be tested for. We do not try to make portable software (though writing software that works across all versions of Windows since 95, and especially those based on the NT kernel, is easy to do accidentally). Customers do always have the option of asking for additional target systems, but they may incur a time/cost penalty due to extra testing and e.g. engineering around features that one platform has and another does not.
Generally, customers choose delivery time over portability.
A smaller effort is almost always more desirable than a larger one
Um ok.
I think that’s effort in the sense of development time, rather than effort in the sense of how hard you try.
Shorter development times are generally preferable.
Portability is only worth engineering in if:
a) The product requires portability as a major feature;
or
b) The product may require portability in the future.
This will sound weird, but keeping the portability in mind is a good idea even if you are pretty sure the software will run on one platform only. Ok, it might be counter-productive to make your sw actually run on different platforms, but striving for maximum portability often increases the quality of sw much more than various in-house rules and rules of thumb (not to mention fascist coding guidwlines – the corporate world’s favorite). Seems like it is harder to write some obscure, complete crap if it has to be portable. Or in other words, portable crap is always better than locked-in one.
In principle I want to believe in portability, but I’ve seen a lot of over-engineered portable solutions that aren’t actually better quality. Though, that might reflect the customer’s desire to pay for quality. Having said that, obscurity can still be portable.
As an aside, though we target one Windows platform (typically), we do stick to the documented APIs, thus guaranteeing a certain amount of portability to later Windows platforms. I guess the issue is that there are levels of portability.
I agree about coding guidelines though. Mostly they address the wrong issues. Yes, well laid out code is important, but does it really matter if I use 3 spaces or 4 spaces to indent?
“but striving for maximum portability often increases the quality of sw much more than various in-house rules and rules of thumb”
Besides that you’re not able to know what the popular platforms are in 10 years while you’d still want to develop and sell the software for 10 years. IBM faced this problem with Lotus Notes. So keeping your software portable gives you more freedom on that level, more possibilities regarding flexibility of future business plan.
However, question is wether is more expensive to make the software portable when such situation is needed versus wether it is more extensive to maintain the software’s portability.
Microsoft doesn’t care for portability since they only want other developers to develop for their platform.
Who uses three space tabs??? It’s so unnatural!
Who uses three space tabs??? It’s so unnatural!
I know, but three space tabs are officially required by our coding standards. Unfortunately trying to get it changed to four spaces meets with calls of “It’s just what you’re used to.” Trying to get it removed altogether, well… Don’t go there.