Innovation through constraint

This morning I had a thought which was roughly speaking, fifty percent interesting and fifty percent horrifying. Actually no. That latter fifty percent should be split into twenty five percent for horror and twenty five percent for depression. Actually no, that twenty five percent for depression should be split...Maybe this would be easier if I just explained what the thought was? I think so. Then the complex mix of emotions I experienced should hopefully be self explanatory.

I was thinking about innovation, how it arises, where it comes from, how to bottle it and sell it, that sort of thing. I was looking back at my own career in computing to date and thinking of examples where I witnessed, or took part in, the production of something innovative.

A common thread runs through all my memories of innovation events. In all cases I can think of, there were serious engineering constraints afoot. For example, I remember a time when the system I was working on had to work in 1K of RAM. (Yes, you read that correctly.) I remember a time when a system had to fit a myriad of user options intuitively into an 80 column black and white screen. I remember a system...etc. etc. All the examples I can think of included this sort of constraint.

I see two ways to rationalize this. The first via philolinguistics. It could be that the very definition of innovation in the world of computing includes the idea of suceeding in the face of some constraints. After all, this is (for the most part) a real-world engineering discipline right? You know the drill: "time, cost, quality. Pick two." We eat and drink constraints in engineering. It is what makes engineering, engineering. Put another way, if there are no constraints, it ain't engineering. I can buy that.

The second way to rationalize it is the apparent truism that necessity is the mother of invention. Ingenuity appears to be boosted by the sort of strictures that plague our daily engineering lives. At least it is in the case of those engineers that posess that most precious of all engineering personaility traits - a "can do" problem-solving mentality.

So it would appear that constraints are good. This leads, of course, to the curious phenomenon whereby the very things that cause innovation to happen are the things that the innovators themselves moan about the most. I sure wish I had a supercomputer under my desk. I sure wish I had 4 gig of RAM, twice as many pixels, a faster hard disk, a quicker internet connection...

And now comes my horrible, tentative conclusion. The best way to foster innovation in an engineering crew is to give them a set of constraints. If they are not moaning about the constraints, keep adding them until they start moaning. Then you have created a wellspring for innovation to happen.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine