The case of the foot snuggies
This post is about the lessons in software engineering we can learn from Dr. Nobel Prize. For those of you who are unfamiliar with this Sesame street character:
Dr. Nobel Prize invents really useful stuff in his lab . But… every time when, after years of work, he reveals a new invention to Kermit, the Dr. is disappointed to hear that the invention already exists. Anyway, just watch the YouTube video about a new invention called “foot snuggies”, it’s brilliant:
I think all software all professional software developers can relate to the Dr. , because it is a trap we all fall into once in a while.
The “Reinvent The Wheel” anti-pattern
It all boils down to avoiding the Reinvent The Wheel anti-pattern: unless you plan to learn from the invention process, don’t reinvent the wheel. Dr. Prize learns us the important first step in avoiding this anti-pattern: stay up to date; know what others are doing. Otherwise you won’t even realize you are building your own foot snuggies.
What pragmatic developers should do to avoid the reinvent the wheel anti-pattern in my opinion is:
- Be aware of existing libraries and frameworks before you start your own project. At the end of the clip Kermit remarks: “Maybe if you just watch television once in a while”. The same thing is true for software developers, just replace “television” with “blogs” any other modern news medium.
- Study existing algorithms and design patterns while writing your code. What helped me a lot in the past months, is reading the source code of open source projects and compare it with my own. This can help with making design decisions. If you’re building an ORM for example, an (not necessarily the) answer to almost any problem you’ll encounter can be found in the NHibernate source code.
One thing to avoid here is the “copy-and-paste programming” anti-pattern: building your own code mostly by copy-and-pasting existing code. (Although I think it is ok to sometimes “borrow” code fragments 😉 )
- If you’re reinventing on purpose: find out which features you would like to see in existing solutions and try to implement those features in your own project. That way, the project may become useful beyond the learning experience.
So, I don’t think it is always wrong to reinvent stuff. For example, I started writing my own ORM. Not because I think I’m working on a brilliant invention (look at me! I can automatically construct objects from database rows!), but because I feel the skills I learn from building one from scratch are much more valuable than those I would have learned from becoming an expert in in using an existing OR mapper.
Related (external) blog posts: