The provocative title of this post, is one of the many great points made by Jessica Kerr at the morning keynote at today's GOTO Copenhagen. The keynote was called "Forget Velocity, Let's Talk Acceleration"
Jessica Kerr gave an energetic talk, which covered a lot of ground - enough for several blogposts, which I hopefully will get around to write in the next few days. This blogpost, however, will focus on the point expressed in the title.
Most of us have come across developers, some of them quite good, who suffered from the not-invented-here syndrome, i.e. they'll rather spent the time it takes to write the code themselves, instead of using existing code written elsewhere.
There are probably cases where it makes sense to write it yourself, rather than reuse or modify code made elsewhere, but it is rarely the case. Usually, it takes a lot of time and effort, and it ends up being not as good as the code you could have gotten elsewhere.
I've seen it happen from ORM over logging frameworks to even an entire Ajax framework.
I have always assumed that this happened because of the arrogance of the developers in question, who thought they were better than everyone else.
Not so, says Jessica Kerr - it is due to mental laziness.
This is based on the principle that programmers find it easy to invent new things, but hard to analyze existing code. This means that it is mentally easier to write a framework yourself, rather than take in a framework written by someone else, and get to understand it.
Or put differently, the mental energy you have to spent on writing the framework yourself is less than the mental energy you have to spent on learning a new framework.
Thus, people who suffer from a not-invented-here syndrome, are mentally lazy.
This resonates with me.
One of the followup points that Jessica Kerr made, was that if you look at something, and think that you should rewrite it, then you should stop up, and make sure that it isn't just mental laziness that is speaking.
It is often necessary to rewrite existing code, but rarely to the extend that developers and architects wants to do so. Rewriting the code, however, spares the developers and architects for the work they need to put into analyzing and understand the current code beyond the basic level.
So, in conclusion, rewrite code if necessary, but make sure it is really necessary, and not just done to avoid the hard work of analyzing the existing code.
Disclosure: This blogpost mentions the GOTO Copenhagen 2017
conference. As a blogger who blogs about that conference, I get a free
ticket from the organizers. The organizers don't dictate what I write
about, and don't have any say about the content of the posts.
Pointless Confirmation - Here’s another example of confirmations that shouldn’t happen: If I don’t like the choice, I’ll just change it back, easy peasy. More significantly, I alre...
2 years ago