Reblog

Not Reinventing The Wheel?

It depends.

Have you ever been asked to not “reinvent the wheel” by a customer or maybe your boss to implement some functionality for an existing project? It’s a pretty common situation I think. Extension by reuse is a nice thing to have and all well crafted projects with low technical debt are ready to be improved without the need of “reinventing”. But what exactly the boss is asking to the team? The boss is probably just afraid of the team writing the same code twice, without copy pasting (!). If you’re lucky maybe your boss is smart enough to imply “writing the same code twice instead of reusing already existing components”. Anyway, the final goal for the boss is to reduce developing time as much as possible without you wasting time re-thinking something that is already built in the application.

The problem is that to know if you can reuse effectively, you need to know the code-base. If the methods are 100 lines long with high cyclomatic complexity values, chances are that they are very tied to specific use cases and the business logic is scattered across the sources without the necessary modularization. Let’s say you agree to work on this project by just re-using the existing classes and hoping everything will be smooth and easy. The reality is that to avoid to reinvent that wheel you’re now forced to add even more conditionals, follow convoluted paths and potentially breaking other use cases (especially for low test coverages).

What happened? The new feature could potentially take twice as necessary to pay for those wheels that were not reinvented. Second: the wheels are now more tangled than before and exponentially more complicated. The solution is not of course to re-write the code (even though you might be forced to if the situation is desperate) but to apply the legacy code workflow (cover with tests, extract logic, refactor). If your boss fails to understand that the price to not reinvent the wheel is way higher than extending well crafted software, then the project is doomed. This seems often the case for startups with the need to monetize as fast as possible and sell the mess right after. By the way, why do you think your car repair shop wants to call you back to give you an estimate about the damage of you car before moving forward?

Let’s say you explain the danger of accumulating technical debt to your boss. You shouldn’t be tempted to consider copy-pasting a faster alternative to deal with the mess. Reuse by copy-pasting is possibly more exponentially dangerous than spreading conditionals across the code. It’s just a matter of days that you’ll find your self fixing the previous use case forgetting about the copy-pasted-changed added functionality. Seriously bad idea.

Conclusions

So the next time you’re asked to not reinvent the wheel, instead of blindingly accept on the spot because you totally agree, you have to know what the current state of the code is and only after that you can give an informed answer and a meaningful estimate.