21 Rules of Thumb How Microsoft develops its Software

21 Rules of Thumb %u2013 How Microsoft develops its Software

There are some good points, but if it is true, wow, there are some great oppurtunities for the little guy, or more so, the open source movement to really put a hurt on Microsoft.

The other thing, is errant corp speak, and the fact that MS employees have bought into it. A sub vision thats going the wrong way… (and I doubt that Bill is involved in it). Eg when you actually start to believe certain mentalities, that your processes are the best, and you can do no wrong, it usually means failure is around the door. Throw in more touchy feely philosophy, and disaster is on the horizon product wise. Otoh, MS has some great marketing, and as such, I’m sure they will do fine, even with upcoming product failures.

I used to have a very high opinion of MS, until I started taking some of their training classes, and then reading this blog post. I still have much respect for their marketing practices, although I do wonder about the ethics of their business practice.

Based upon the blog, I also wondered if this was true, or was a method of competitive disintelligence. After thinking some more, I think there it may be true. Here’s a couple of examples that show we MS stays away from certain markets, and why systems integrators should stay away from MS.

Years ago, my banker was crabbing about how un-intuitive his banking programs were. To me, it looked like some type of CPM program that got ported a few thousand times…

At the time, I thought, gee I wonder why MS doesn’t go after this market. Based upon the above article, on their software practices, I can see why they don’t.

I have seem some MS products running medical equipment. Thats really encouraging. So here we are, we have the patient breathing a radioactive tracer… Guess what, blue screen of death on the control panel. Now isn’t that comforting. At least, the tracer atmoizer does not run under software control… but still, the test has to be redone. So the patient takes 2 hits of radioactive vapor, just because of MS development methodology. Then again, the system integrator should have been shot for using a MS product in a critical application. I have no idea how such a machine made it past the FDA.

On a positive note, some of the communication processes mentioned in the article were of value. But I can also see a leaning toward micromanagement of tech professionals by managers who don’t have a clue. In other words the Dilbert scenario to a T. However, with a good management structure, such principles do not result in a Dilbert scenario, and could help with development efficiency.

There was also a little bit too much of philosophy, rather than going out and getting things done. Do we see the potential for bloated code here…. Anyone who has developed commercial code will know exactly what I’m getting at.

Comments invited.