I’ve recently finished reading Richard Dawkins’ The Greatest Show On Earth book. It’s a book about evolution and I think everyone interested in evolution (either for or against) should read this book. Even if you don’t believe in the idea of evolution, the wealth and detail of scientific information he provides are well worth the read.
One thing that struck me about this book is that Richard Dawkins provided “unintelligent design” as evidence for evolution. He pointed out some major biological design flaws in various animals to conclude that an intelligent designer could not have designed those animals with those major imperfections. Therefore, somewhat random yet adaptable process must have produced that animal with those imperfections and made that animal survive up until today. The argument is very convincing and I don’t want to provide all the details to spoil the book for you, so go and read the book if you’re interested.
Now back to software development. I’ve worked at a number of companies and projects by now and in every project I worked on, I always came to the point where I questioned the design of the software in some shape or form. “Why did he design it this way?”, “Why is it so unnecessarily complex?”, or “This is so stupid” are some remarks that crossed my mind at one point. While some of these are valid concerns, they miss two crucial points.
First, there’s never a single designer in software development. In every project, there’s a bunch of developers and one or a few architects agreeing on a framework on how to solve a problem. But at the end of the day, what’s agreed is just a framework or a guideline, and it’s up to the individual developers to reflect that agreement into code. That can vary greatly from developer to developer and when one developer leaves the project, another developer with a different experience picks it up. So, every piece of code you look at will be influenced by an architect, implemented by one or a few developers, and tested by a quality engineer to further shape its design. There’s not a single designer that you can really blame.
Second, software development is not perfect. In Math, there are facts and there are proofs to support those facts. Even though there’s some flexibility involved in writing the proof, most of the times, the process is quite strict, you either have an agreed proof for something or not. Same goes with civil engineering. Your bridge either does its job of moving people from one side or another or not. There’s no middle ground. However, in software development, there’s quite a bit of middle ground. Two pieces of software that might work the same way can be implemented on totally different platforms in totally different ways. The digital nature of software development makes it very flexible but with that flexibility comes imperfections. An inexperienced or careless developer could easily make something work in an imperfect/non-optimal way and you end up with systems where things work ok but they are not perfect in the same sense as a mathematical proof is perfect. You end up with imperfect software that work just like you have imperfect biological organisms that survived up until today.
After reading this book, I found it quite useful to remind myself that software is very much like an evolving organism. There’s no single designer, there are imperfections but at the end of the day, it just works. So, instead of questioning the imperfections, blaming the non-existant single designer, and trying to upgrade every single piece of code to its theoretical perfection, I learned to embrace software for what it is today and add survival value for its next generation.