Monday 21 April 2008

Cutting your Losses

Just read Peter Bright's article on a Windows user converting to Mac, but from a very well balanced and unique developer perspective.

I have to say that placing myself in mainly the .NET Framework, my experience of Windows behind the scenes isn't as tarnished with bad experience, but from my general usage of Windows I can really see where Peter is coming from.

It seems like Microsoft's unwillingness to make major breaking changes in their API (and therefore break many high value enterprise apps) is a major contributor to the general poor quality of Windows today. Apple on the other hand cut their losses, deprecating functionality and introduced a new OS from NeXT enabling them to write modern powerful APIs such as Cocoa. This allowed them a platform to support several high quality industry standard apps such as Final Cut Pro, Aperture etc.

From the article:
"Microsoft has never done anything so bold as Apple's OS X transition. It developed a new, modern OS, but did so in the early 1990s: Windows NT. And although Windows NT ticked the right boxes at the time—protected memory, preemptive multitasking, multiprocessor, written in platform-independent C—in places it was never even close to modern. Its APIs were based on the Win16 API from 16-bit Windows. This was a deliberate decision, as it made it easier to migrate 16-bit apps to the new 32-bit platform, and at the time it probably made sense. But it means that nowadays the 64-bit API (Win64) still reflects decisions made 20 years ago."

I can understand the predicament - but in software my humble opinion is that the quicker you cut your losses the better - code the right way from the beginning and re-factor as much as possible.

Perhaps my opinion is blinkered, blindly ignorant, who knows - you can always post a comment :)


Anonymous said...

From what I understand Dan, Microsoft are kind of doing this in Windows 7. At least, to some degree. They're working on a new Kernel (google for MinWin) which will be much more streamlined.

I can't say what they'll be doing for APIs, but I'm pretty sure the UI side of things was updated heavily with vista and will no doubt be updated again with Seven.

I guess Microsofts user base is their problem, they have to balance upsetting vendors with enterprise applications which will suddenly break horridly with making breaking API changes.

Anonymous said...

The issue of how long to support an API is complex. If you had spent years developing a codebase for a really big application you would not react kindly to the rug being pulled from under you, even less if you had paid millions for such a system. I believe that End Users should expect their systems to run for at least 10 years and so API and O/S vendors should support for 15 to 20 years.
Of course legacy API support pushes up cost and creates bloatware - there is nothing wrong with creating a new architecture but then you have two products and support for the old product needs to be maintained.
Lack of support for older systems is what drives people away from Microsoft. Maybe you haven't lived long enough yet, Dan.
Why should my father have to buy a new computer just because he can't buy a new printer with Windows 3.1 drivers?

Alan R

Neil Robbins said...

I can think of a legacy codebase that needs to cut it's losses and be radically overhauled.

Can you guess the product Dan? :)

John Goode said...

Neil Robbins — spot-on! Cut & run; there ain't no point in flogging a dead donkey. Or even; 2 dead donkies!