Microsoft and Software Development

There was an interesting article in www.zdnet.com/zdnn regarding OSS vs. Closed Source Software, and the huge number of anti-Microsoft postings, some of which I agree with, others, plain stupidity. After reading the article and comments, here are some of my views.

Closed source software doesn't have to be buggy, bloated, inefficient, and security hole ridden. The vast majority of programmers in the world, including those in Microsoft, do not want to create buggy, bloated, inefficient and security hole ridden applications, not necessarily because of the impact, but because of human nature. When a person does a job, and has a passion about that job, say, a programmer, they put 100% in, and the majority would rather walk away knowing what they did was a good job. When it does hit the marketplace, people use the product and for the most part, are happy with it, and the programmers are happy because what they have produced has satisfied their customers.

Many people, especially in this group blame a number of groups and/or people for the poor quality of software from Microsoft. A small number in COLA will simply state that the software is poor quality because it is closed source, mainly because it is not developed under the GNU license. Another group simply blame the popularity for its vulnerability to virus's and security issues, and claim that if Linux had the same popularity of Windows, it would face the same issues. The remaining group blame the marketing department in Microsoft for its need to rush products to the market place before adequately testing software, especially in the area of operating systems.

So, what do I believe is the one cause? I believe the cause is not at one point, but at three points.

The first point is in marketing, the failure to realise that that is what their task is, to market, that is it, not to decide when a product should be launched, or whether a product is ready to be launched. The best move by Microsoft would be to get rid of its inside marketing department and out source it to the likes of Saatchi & Saatchi who come in only when required, and have no decision in how or when the product is ready.

The second point is in leadership. There is a failure in leadership in regards to the fact that a large number of executives are not technically minded and fail to realise the full scope of a development process, and as such, place unrealistic development times on developers.

The classic example would be the transition from Windows 2000 to Windows XP. Windows XP wasn't a mear upgrade, there were major kernel changes, yet, the expectation on the programmers at Microsoft was that they should ship it in 18 months, which was a totally unrealistic goal. When Windows XP was released, there was a list of bug fixes a mile long, and large portions of the Windows XP SP1 have already shipped in the form of hot fixes, many of the issues could have been fixed through better beta testing and a longer development cycle.

For intensive purposes, Windows 2000 is a pretty good product in terms of stability, security and reliability. This was due to the longer development process. Microsoft should have shipped Windows 2000 in 2000, then pushed the next version of Windows out to 2004-2005, and maintained a service pack release cycle, based purely on fixes, every 6 months, thus, over 5 years 10 service packs would have been released. In terms of features, such as support for new devices, these can be a seperate download off the Microsoft website, and thus, ensuring that the basic OS remains in tact. Once fully tested, that is, say, the new device addition is for USB 2.0, has been tested for 4-5 years, it will then be ready to be merged into the main trunk of the Windows source code. The same situation can happen in the case of the server versions of Windows through a registered early release connection for a small fee where by people can have access to the latest version of say IIS, so that those who wish to keep with the current OS and move forward on the server application front, they can, those who wish to keep with the status quo can, thus, again, after 5 years of extensive testing, it can be then merged into the main trunk of the Windows 2000 server source code.

Company culture is the third issue that courses problems. This is spun off from the leadership issue where by features are more highly prized over producing stable and secure products. As I also previously covered, many of the executives at Microsoft fail to realise that with ever new feature added, new security holes and stability issues are brought about. Windows XP is the prime example. Windows 2000 is just going to become reasonably secure when SP3 is released, and Microsoft wants to release a version of Windows which includes a whole new set of features and major kernel changes. They assume that there will not to be any security and stability issues arise even with such a heavy OS overhaul? it is pretty naive in assuming that.

When you add these three issues to the mix, you end up with Microsoft. A company lead by people with a lack of realistic vision and timetables, and expect that by simply telling the coders to code perfectly, everything will be solved. It won't be until they address the three key issues I have talked about.

Matthew Gardiner

My company is purchasing an as-yet-uncompleted piece of software. It is very function- and client-specific in that no other company, even our competitors, could use this software. We have hired a group of programmers and others who are savvy in our business, and we asked that they follow the business rules we gave them. Unfortunately, when they gave us a timeline, they didn't take into consideration the amount of detail we went into in the business rules (nearly 200 pages of specs).

Being the unforgiving company that we are, we told them they could not have more time to deliver the product. So, they opted to write a code generator that can accept our rules and produce working code. The upside to this is that they can provide the package on time, but the downside is that the code generator is not so intuitive as to realize that a bit of code can be reused with a call, so there are thousands of bits of code that are nearly identical, each with its own heap.

The final product is estimated to be 143% larger than originally estimated, and the necessary support files will require we add another disk pack (it's a mainframe, but the point is the same).

My guess, then, based on this company's solution to an underestimated timeline, is that Microsoft and others this WYSIWYG sort of programming and hope the screen looks right in the end. Code intimacy, it seems, is not considered a requirement to producing applications.

Sorry, couldn't resist.

The title sounds kinda like one o' them oxymoron things.

No need to apologise I get your drift. MS and quality is indeed an

And also lack of knowledge about the product and what it does. Marketing does perform some useful functions, especially in terms of educating people about what your product actually does. This is important for selling to PHB's, not necessarily to techies.

Yep. Marketing was indispensible on that one!!

Also, if I want to use a piece of software, I will findout about it, and I will decide whether it is worth buying, not by simply listening to the local hype(tm) corporate(tm) ad from Microsoft(tm).

Lotus has no ads for Lotus Smartsuite, yet, I still use it, because, I use what works, not what is hyped the most. Microsoft can hype, hype, hype their products to kingdom come, but it isn't going to make me buy their software.

Matthew Gardiner

Development and production are two different things. Yes they can develop, but can they turn it into a working and quality product, no.

Matthew Gardiner

Sun, 23 Jun 2002 at 14:42 GMT, peering quizzically at his shoes,

Just in case this is a problem you'd appreciate help solving, and not just a general gripe, you can always install packages without removing the old version.

'rpm -ivh new_libpng.rpm'

would probably have done the trick in the specific case you mention.

As with all things, if you learn how to do it in the general case you won't have such a hard time solving the specific cases.

It was a bit of each partly generated by endless dependency problems, and partly because I did want to get dillo going, it's a great browser for looking at most helpfiles.

error: failed dependencies: kdeaddons < 2.2.2-2mdk conflicts with libpng3-1.2.1-8mdk kdebase < 2.2.2-37mdk conflicts with libpng3-1.2.1-8mdk kdebindings < 2.2.2-4mdk conflicts with libpng3-1.2.1-8mdk kdegames < 2.2.2-4mdk conflicts with libpng3-1.2.1-8mdk kdegraphics < 2.2.2-4mdk conflicts with libpng3-1.2.1-8mdk kdelibs < 2.2.2-29mdk conflicts with libpng3-1.2.1-8mdk kdemultimedia < 2.2.2-3mdk conflicts with libpng3-1.2.1-8mdk kdenetwork < 2.2.2-11mdk conflicts with libpng3-1.2.1-8mdk kdepim < 2.2.2-2mdk conflicts with libpng3-1.2.1-8mdk kdetoys < 2.2.2-6mdk conflicts with libpng3-1.2.1-8mdk kdeutils < 2.2.2-6mdk conflicts with libpng3-1.2.1-8mdk

And there's no way I'm