In all advices we receive as software programmer, one of the most misunderstood (just after don’t repeat yourself) is don’t reinvent the wheel.
Of course, it seems pretty obvious that if we re-do everything all the time, the whole industry won’t evolve at all. But when we dig enough, it is clear that all of us do not have the same definition of a wheel.
I would like to explain here that defining what needs to be re-do in your context might be harder than it seems.
The usual suspects
I often hear this argument for 2 main software parts: some User Interface (UI) component and the Object Relational Mapper (ORM).
For the UI this is usually used for complex grid with advanced features like filtering or advanced search for instance.
The ORM is this magic piece of code that let you manipulate data in a database without even think about it.
In both cases it seems perfectly reasonable to suppose that it will accelerate your development workflow to use them. Because after all your job is not to fetch data from a database or even to display them in a nice filtrable grid.
The success stories
I do not have any scientific data to demonstrate what will follow, and I admit gladly this is just gut feeling. I’m ready to bet though that many of you may have done the same experience.
You use the awesome UI component, and you’re able to deliver in production pretty fast. You can impress the stack holders during the demo thanks to many features in the UI. Most of them won’t be used but you know, who can do more can do less!
The story with your ORM is quite close, everything is working and you didn’t write a single line of SQL. Database migration is automatically handled and you don’t need to know how it works. How glorious is that?
This is by the way where most tutorials stop you’ll have to discover the rest by yourself.
The limit of the approach
One morning a user calls you: “I don’t understand why it’s so slow since the last update?”
The problem is that you don’t know either, worse it’s not that bad on your machine. A few logs and search later, you nailed it, one of the queries tries to fetch 80% of the database just because someone in the code try to get some unrelated data in a weird way. Weird in a SQL point of view, but not that weird when your ORM hide it for you. And then you have to understand how it works under the cover in order to avoid the normal behavior of the ORM. It usually leads to untestable code in order to achieve your goal without performance issues.
Soon after that, during the next spring planning, the users will ask for a “minor” UI change in the way we can filter data. And again, you will need to understand what’s under the cover in order to understand how to change it according to your user’s wishes. But the thing is that the theory of the framework will probably not match your program’s theory. And it will take a lot of hacky code and long hours of tests to make it work.
And this is without talking about the bugs (or misuse) of the libraries you’re dependent on. It could be quite long and frustrating to wait for other developers to fix a behavior important for your business.
So what’s a wheel?
To be fair, it depends on your context, and project maturity. But basically, a wheel is something that is becoming a commodity through time (Wardley’s map could help to see and understand that not everything can become a commodity). Most famous examples might be electricity, the internet and now cloud computing.
Of course you certainly not need to build your own database, and not even to host it. But thinking that you can build a complete product by using mostly existing libraries and frameworks is also a myth.
Using other libraries to build a solution faster can make sense when you’re exploring a problem.
But at some point, you probably need to replace them with custom components where you can have a complete control. This “inflection” point is hard to find, and most companies fight to keep things as they were instead of looking to what will be required at their maturity stage.
A software wheel is something that you don’t need to care about, in your context and at your level of maturity. Hence the hard part is that it will change through time.
Try to keep an eye to understand where your bugs come from and what part of the code is harder to maintain. It might require to change “a wheel” by a custom part to take full control of the behaviors.
So do you have similar stories?