innovation for innovation’s sake
I started this one a long time ago, and never actually filled in any content. It’s something that I think about a bit when it comes to developing software. The temptation for anyone passionate about technology is to be inventive and clever about their development, in an effort to challenge themselves and maybe show off a little too.
This all came to me a while back when I was looking for a new cell phone. So many of the phones out there were either terrible or over-developed. One example would be the Nokia 7280 – an awkwardly sized phone with minimal display and no keypad designed to be “fashionable.” Just because you *can* make a tiny lipstick phone doesn’t mean you *should*.
Recently, I wrote a bunch of stuff stemming from my read of Eric Raymond’s “The Cathedral and the Bazaar.” This ends up being connected as well. At one point, he says:
“…the problem with being clever and original in software design is it gets to be a habit – you start reflexively making things cute and complicated when you should be keeping them robust and simple.”
It seems like such an obvious statement, but it so often is something that is ignored. Great engineers will run amok. It is their way. It should be nurtured. However, it should also be harnessed and pointed in a direction when needed on a project. Occam’s Razor applies – “entities should not be multiplied beyond necessity.” Nine times out of ten, the most important factor in developing… well… anything, is speed of development. Cute and clever never won any races. People want their house built ASAP; that website needs to be done ASAP. Often the obvious motivation for this is opportunity.
By having exactly what you need as soon as possible, you’re better equipped to respond to market opportunity. Need is the key word in this sentence. Sitting down and defining what you need in order to be functional is essential in developing anything. That involves chunking down that massive list of wants and giving them some kind of priority.
Clearly, when Nokia innovated that tiny phone, of utmost importance was size. All effort was exerted on making it that size, that everything else was pretty irrelevant. In that case, the priorities probably looked like
- design casing
- fit cell radios in casing
- add speaker and mic
- add buttons to control talk/end
- add display to see status
So much effort was expended on the first few items, that the last few received insufficient attention, and suffered because of it.
Everyone that knows me knows that I’m a bit of an Apple fan. And a Toyota fan. (p.s. I own a mac, but not a toyota) Both companies do an excellent job of setting their priorities in order, and sticking to them. The iPhone is a good example of technology that is extremely innovative, but not over the top and useless. Apple set out a list of goals (conceivably: sexy design, maximum display size, reuse mac software components, slick user experience) and met them. Is there anything on the iPhone that is too much? I’d say no. There may even be stuff that’s missing, but that’s *good*. They developed the product that they hyped, and it satisfied immensely. Now they can improve on that by adding little bells and whistles as time goes on.
I’ve experienced this in software development too. The first time I set upon a totally gargantuan tear-down effort, I didn’t fully understand this concept. Fortunately, our task was to mimic the current features and design, so little additional innovation was welcome. However – the temptation to go hog wild snapping in new behind-the-scenes toys was nearly irresistible. Good thing we had an unrealistic timeline. Was the tear down worth it? In this case it was absolutely necessary.
The second time I found myself faced with a massive lumbering project, again it was under a major crunch. Not only for the usual “I want it yesterday” reasons, but also because the company had been suffering for years under the previous setup, and was impacted on a daily basis. This time, I had the appreciation of “only what is necessary for launch.” Having learned all the fun agile tricks, and working with a very amenable business owner of the project, I was able to express this method and get total buy-in. After a protracted discovery phase, we sat down with the engineers and explained the problem to be solved. As a group, we threw needs up on whiteboards, worked them out, whittled them down, and threw some out. There were some truly innovative solutions to the problem that were presented. Solutions that are entirely doable. Also, solutions that were totally unnecessary to have a functioning system.
In the end, we delivered a system that did *exactly* what was needed in the simplest possible way.
The challenge of fostering innovation while preaching simplicity is the daily life of a really great tech manager. I worked hard to encourage engineers to be clever and inventive and break new ground, but they also learned a fine appreciation for developing things as simply as possible. When you’re lucky, the clever solution turns out to be the simple solution.