Cracking creativity

I’ve started reading Michael Michalko’s Cracking Creativity now, and it seems very promising. The first chapter is about looking at a problem in many different ways, trying to break free from your preconceptions. Michalko gives very helpful examples of how thinking differently about a problem can make it more easily solved. Reading this, I came to think about a problem that was tough for me and Malte a few months ago.

We were building an application where we knew we would have to maintain historic data, since reports should be generated based on what the data was at a specific point in time (ignoring later edits). Any solution we could think of had drawbacks and some of them were very complex. Also, we didn’t have all the requirements yet, so we were reluctant to go ahead and design this, since we feared that any differences between our guess and the actual requirements could yield in lots of time-consuming changes. (Also, we wanted to put pressure on the people that were responsible for stating the requirements.)

This feature became something we deferred time and again, both hoping that it would prove to require a much simpler solution as we learned more about the problem domain, and fearing that we would have to make big changes anyway, when we approached it again. Then, eventually, we scheduled the task and went to the whiteboard to see what we could do.

I’d say that waiting was beneficial since we had learned so much about the domain. But it’s also true that by waiting so long with this high-risk task, we had shut a few doors on ourselves (since those solutions would have taken too much time because of wide-spread changes) – which might not be that bad, I guess, because we were really happy with our solution. It felt obvious when we discovered it, which is a sure sign of something good.

If we had followed this book, we would have tried to restate the problem in many different ways, looking at it at different levels of abstraction. What we did was basically to try to come up with as many solutions as possible, and verify the requirements against each one, discarding those that were impossible and learning from each attempt. Although that’s intuitive to me, perhaps it’s a slower approach than to spend more time with the problem. Michalko quotes Albert Einstein as saying – in response to a question about what he would do if there was a comet on collision course with Earth, estimated to hit in one hour – that he’d spend fifty five minutes studying the problem and then five minutes working on the solution.