Wednesday, January 04, 2006

Happy 2106!

Contrarian investing often pays off; let's try contrarian software engineering. Instead of thinking about the deadline that's a month away, consider the time frame of a century. The following Gedankenexperiment is important because it's usually easier to scale the problem down than to scale it up.
The Exotic Contract.
You are leading a team of software engineers, and you are offered an unusual contract: develop, maintain and enhance a software system over its 100-year lifespan. Here's the kicker: you are paid a lump sum (a really big lump sum: say, a billion dollars), not by the man-hour. (For the purposes of this thought experiment, how the feature set is negotiated, how the deadlines are set, and the impact of inflation are not of interest.) How you allocate the money over time is completely up to you. You have to optimize the software development process over a period of a century, and every dollar you save in the long run goes directly to your bottom line. What is the most profitable course of action?
The industry-standard approach is to develop a system and rewrite it, usually component by component, every several years. This makes sense when you are coding for a start-up that can go out of business in six months. But if you sign the 100-year contract, it is guaranteed to be a long-term project. Is throwing away code every five years really the optimal way to proceed?

Let's look at the world of computing with a 100-year perspective. Will Win32 API be relevant? No, it will be forgotten within decades at most. What about HTML? Chances are, another standard will come along. On the other hand, the concepts of 'an integer' or 'a string of characters' or 'a transaction' will still be useful. With a bit of foresight, entities can be categorized as either timeless or fleeting.

Here's a different approach to the exotic contract problem. First, select abstractions that make up a "timeless" platform, and have two parallel efforts going on: one to develop applications on the timeless platform, and another to map the timeless platform to existing software platforms such as Windows and the Web (possibly with some application-specific hints.)

For the world of databases, the relational model serves as the timeless platform: application programmers use it, and DBAs give hints by optimizing logical and physical data layout to gain maximum performance. However the relational model is not suitable for general-purpose programmingit lacks important abstractions such as 'a sequence' or 'an object'. There is no universal timeless platform available today: if there were, everybody would be using it!

Even if no one's knocking at your door offering you an exotic contract, the exotic contract problem itself is an important one. Companies come and go, but the software industry will be around for a long time. Looking at all the software development efforts as one enormous project, it makes sense to take a bird-eye's view and optimize it for the long run: there is a huge economic incentive to do so.


Anonymous Anonymous said...

my only thought would be a business one: why wait longer than I have to for not just a return but also a profit on my investment, given my short lifespan, desire to have it all now, etc?

If all business worked on a long-term consideration, this post would never have come into your/our consciousness (perhaps).

7:14 AM  
Blogger Norman said...

Wonderful idea you have.

However the basis for a relational model is an object and making relations is a sequence, so why should I stop at the level of relationality for databases?

And thinking of the future of programming, might be a good idea to ensure that you make software that is forward compatable. This would also be a saving over the current system in which we always seem to try to be backward compatible.

But maybe the most important element is starting to think in object that can be used in several applications. A bit like Apple tried at the beginning of the nineties with its compartemented applications, in which every application only did a small action with an object and handed its product over to another application. Which made it possible for the user to build his own applications, instead of buying the current behemoth applications of which we only use 20% if we are lucky.

3:05 AM  

Post a Comment

<< Home