Why do we find it so hard to innovate?
I had lunch with a good friend of mine recently, and our conversation veered towards the lack of innovation in the company he works for(which incidentally was mine a year ago). We had some thoughts on the subject, and on my way back to work, I kept wondering why we didn't have world-class innovations from India, particularly in the software field in which we're supposed to be so strong. There are a few reasons we all know - don't we? As software engineers, we are trained to write software that implements a spec. We are trained to re-use, to borrow readily available code/design, and to think in patterns. None of which are characteristics that encourage innovation. There is also our education system, my favourite whipping boy for everything that is wrong in the software field. We are not encouraged to tinker, we are not encouraged to find our own answers - instead, we learn, by heart, answers handed down to us. What better way to kill the innovative spirit?
File your opinions through the comments link below.
The Ancestor's Tale
This is another "wow" book by Richard Dawkins. I'd read his Selfish Gene, Extended Phenotype, Unweaving the Rainbow earlier, and this is a wonderful progression of Dawkins' talent. The Ancestors Tale recounts the story of evolution, going back in time to trace the lineage of the human species. The book is full of facts, evidence, and anecdotes - not to mention the occasional funny diatribe against Bush, Creationists, and their ilk. As usual, Dawkins writes marvellously well, and while there are sections of the book that a non-biologist (me) may find tough to understand, they are well demarcated, and don't interrupt your understanding of the rest of book.
Dreaming in Code
I wouldn't have heard about this book by Scott Rosenberg if it wasn't for my favourite software blogger, Joel Spolsky. While Dreaming in Code is a biography of the Chandler project, it goes beyond just that, giving the reader wonderful insights into why Software is HARD. Why is it, that 50 years after the first high-level language was invented, we still don't have a language to convert requirements into code? Why is it that, 35 years after Dijkstra announced that the "Goto statement was harmful", we don't have a language that'll minimize logical errors? And why is it, to quote the immortal words of Fred Brooks, there is indeed no silver bullet in software engineering? The book revisits these questions, and asks a few more of its own. For instance, it questions the logic that software should be more like civil engineering, it describes the problem with leaky abstractions, and the undecidability of verifying software. While I don't want to say that it is in the same league as the Mythical Man-Month, it is a must read for every software engineer.
Here, I want to make a small point. Software development is about people. It is not all technology. It is about people deciding to do the right thing everytime they put their hands to the keyboard. It is about embracing quality - as Harsha Bhogle eloquently describes in this video. It is about perfecting the basics - remember the "wax on, wax off" lesson from "The Karate Kid"?
Tools can only help. Ultimately, software is all about people. While you are reading this, also take a look at code reads - the collection of trend-setting articles by Scott Rosenberg.
