Software Lock-In Strategy versus Software Architecture and Stability
Stewart Gebbie
20070827

Word processors seem like a simple idea in the big scheme of computing. Yet
the number of problems we encounter is quite amazing. Save a document in one
version of MS Word and open it in another and things no longer look the same.
Bullets and numbering have a mind, note not a very intelligent one, but a mind
of their own. Now try send this document to someone that has not bought into
the Microsoft Empire and uses a different word processor - this is even more
of a shambles.

So why is it that this software giant simply can seem to create stable
software. Be that a word processor that simply does the job properly, or an
operating system that is stable, or a mail server that does not keel over.
Any why, specifically on the note of word processors, is it so hard for any
other vendor to meet the challenge and build a decent word processor that is
compatible with the dominant format?

Lets back up a little, what are the some of the key tenants of robust
software? I would like to suggest that they are:
	- adhere to a good architectural principles
	- adhere to a quality process of development

So what constitutes a good architecture? Well, to be fair there are a number
of different views, but it generally comes down to the following types of
attributes:
	- modularity
	- loose coupling between components
	- separation of concerns
	- minimizing dependencies
	- autonomy of components and locality of functionality
	- structure at different scales (e.g. a hierarchical structure of
	  modules)

And a good development process? Again there are many different "best
practices", but below are the highlights:
	- iterative (cycles of review and development)
	- solution constraints defined explicitly via ongoing testing at all
	  levels (e.g. unit tests, user acceptance tests, etc.)
	- good communication and feedback between all parties
	- reviews and refactoring

Right, lets get back Microsoft and the usual conspiracy theories. One of
Microsoft's key strategies leading to success is "vendor lock-in". "Oh, come
now.", you say. "They just produce products that their customers want". That's
funny, then why the following memo:

	From: Bill Gates
	Sent: Saturday, December 5 1998
	To: Bob Muglia, Jon DeVann, Steven Sinofsky
	Subject : Office rendering

	One thing we have got to change in our strategy - allowing Office
	documents to be rendered very well by other peoples browsers is one of the
	most destructive things we could do to the company.

	We have to stop putting any effort into this and make sure that Office
	documents very well depends on PROPRIETARY IE capabilities.

	Anything else is suicide for our platform. This is a case where Office has
	to avoid doing something to destroy Windows.

	I would be glad to explain at a greater length.

	Likewise this love of DAV in Office/Exchange is a huge problem. I would
	also like to make sure people understand this as well.

I found the reference [2] to this memo while reading an article [1] lamenting
about the problems with Microsoft's "open" format that it is trying to get
ratified by governments and standards bodies.

One of the things that struck me, in reading about the OOXML document format
was the level of dependencies between one part and another. For example, if
manually edits the XML of a spreadsheet document (as you should in theory be
able to), so as to change the contents of a cell, suddenly all sorts of
dependencies show up between seemingly independent parts.

Then look at the server side. You might think that a mail exchange server is
actually fairly simple. I mean, e-mail has been one of the most successful
uses of the Internet and has been around for at least 25 years [3]. You might
be fooled into thinking that this should be a solved problem -- well at least
in terms of stability, simplicity of administration, volumes (maybe not the
spam side or security which are inherent deficits of the original design).
Well, generally this is a solved problem (there are a number of excellent
scalable and robust mail servers implementations, mostly targeting the Unix
style platforms), until you enter the world of Microsoft Exchange.

Again, dig deeper and you find that you buy one mail server get one
calendaring, contacts, tasks for free [4]. Not to mention the general
configuration which depends on Microsoft Active Directory and Microsoft
Internet Information Services.

So what we see is that the a proliferation of dependencies between software
components. A lack of separation of concerns - that is, one component doing
multiple tasks. A lack of loose coupling - causing implicit dependencies
between document (or communication) formats and software. Reduced autonomy of
components - Microsoft Exchange functions best with MS IIS and MS AD. A
blurring of structure across scales - Microsoft services all depend on the
Microsoft Operating System.

That is, we see a corporate strategy of lock-in is completely at odds with the
most of the key principles behind solid architecture.

While it may be hard to quantitatively demonstrate the link between the above
tension and the poor quality software produced, it is interesting to note that
Microsoft is a strong proponent of the other arm of software development - the
development process. More specifically Microsoft as adopted many of the
principles of the agile software development [5] via their Microsoft Solutions
Framework [6,7]. They are also very active in recruiting testers [8] (1.4
testes to every developer) and clearly expend a lot of energy on this
important part of software development [9]. We also see the release cycles
reduced via beta releases and service packs.

My interpretation of this is that quality does matter to Microsoft -- poor
quality does hurt the bottom line and needs to be balanced with the cost of
producing high quality products. However, they are heavily constrained by on
the architectural side, and thus need to create a much larger push on the
software process side.

In conclusion my question is, would you really want trust your business to any
software vendor whose internal corporate strategy is fundamentally at odds
with one of the key areas that enables the creation of simple, robust and
secure software?


References

[1] http://www.arstdesign.com/articles/OOXML-is-defective-by-design.html
[2] http://antitrust.slated.org/www.iowaconsumercase.org/011607/2000/PX02991.pdf
[3] http://www.ietf.org/rfc/rfc0821.txt
[4] http://en.wikipedia.org/wiki/Microsoft_Exchange_Server
[5] http://en.wikipedia.org/wiki/Agile_software_development
[6] http://www.microsoft.com/technet/itsolutions/msf/
[7] http://en.wikipedia.org/wiki/Microsoft_Solutions_Framework
[8] http://members.microsoft.com/careers/careerpath/technical/softwaretesting.mspx
[9] http://weblogs.asp.net/scottgu/archive/2004/10/28/249458.aspx