Reinventing the Wheel: Just How Evil Is It?
Blog >
Why Should the Wheel Be Reinvented Sometimes?
Reinventing the wheel has become like a stigma in today's world of programming. We are constantly told that some people had a godly intelligence to create something that is beyond redesign! You, as a "senior developer" should just use your mind as a bucket of others' ideas and concoct solutions based on those. The more you learn, the more your bucket enlarges so you will ultimatly reach a level of no "wheel reinvention" and finally achieved ultimate "seniorship".
What happened when wheel was no longer reinvented?
The end result of applying no wheel reinvention can be readily seen when having to work with software developed by (most) other developers:
- overly complicated code. Chances are nobody made a solution PRECISELY for your needs, so you end up using something that is needlessly complex, which taxes performance as well as making code hard to understand. In the world of Java or PHP (the other languages I'm competent at) you encounter a profusion of frameworks geared at making above-mentioned bucket enormous enough to fit "everything" a coder will ever possibly need.
- chaos made by programmers who never got their chance to exercise their minds. Obviously, years or even decades of experience while working like a factory robot doesn't increase your intelligence and problem-solving skills. The things you write will always reflect the lack of fundamental logic: zero concern on performance, simplicity, elegance or even common sense. Typically here we find classes doing EVERYTHING, technologies used because developer could not write two lines of proper code, orgies of macros (in C/C++) and an omnious messy look from top to bottom.
- "the standards". Factory work would not be complete without standards. A worker is supposed to obey standards as his second nature! Generally the standards have themselves become standardized, so companies have created tools that check if your code obeys the standards (be it test coverage, code quality, design patterns or whatever). The end result gives the impression of a quality improvement, but real life experience tells you they are to a large extent useless hindrance. Hiring a few competent developers is always a better long term solution (in terms of quality & performance) than imposing standards to sub-standard workers.
- proliferation of individuals that should not be programmers. Because programming is a well-payed job, it has lately attracted an army of people intellectually unsuitable for this job, incapable to do any better EVEN IF they are trained "the standards" or to think for themselves.
This mindset that promotes conformity is responsible for an enormous decline in the quality of programming and can only be addressed by its nemesis: creativity or
"reinventing the wheel".
When should we reinvent the wheel?
Whenever you think you can build a better "wheel" by learning from your or others mistakes, while maintaining rock-solid allegiance to
principles of performance, simplicity and elegance, reinventing the wheel becomes an invaluable vector of progress
IF not fuelled by ignorance/arrogance.
Why should only these principles qualify as programming standards to follow? Because they define a working methodology that imposes no constraints except striving for clarity and perfection. This way programming becomes an ungoing quest to intellectual discovery and delight!