There was an era of modern software development where everybody was busy inventing their own wheels. Remember, no GitHub at this point.
This is not a history article, but perspective is much needed to understand the compelling reasons behind every big corporation creating their own languages, then frameworks. Most of the time they’d start with something that suited their specific needs or speeded up their process.
Since the Log4J debacle we can be sure this is not the case anymore.
Now we have enthusiastic pro bono contributors, corporate employees, and consumers of open source libraries all working together on specialized tools for generic problems within a domain.
logging
auth&auth
routing
load balancing
server-side rendering
HTTP communication
and of course frontend frameworks and web servers. No one in their right mind implements their own version of these. Either use a library or a black box service.
Why did we ditch in-house frameworks?
The more people use these libraries, the more cases are tested, the more useful features are requested and the more contributors will join to improve.
I also use open-source libraries. If I find a bug, I either try and fix it, or open an issue on GitHub. Then the next version is again one micron better. If thousands of people like me work together, that by itself would result in very useful tools. Add some original creators, maintainers, and open-source angels to the mix, and you can easily see, how in-house frameworks cannot hope to compete.
Using a calculator is much more cost efficient than inventing, and assembling your own, from scratch.
And I don’t mean they look at the calculators we have today and try to create their own based on that. No, in-house frameworks are like restarting the evolution and creating the calculator of the ‘30s first.
It’s just a simple thing as a calculator, reinventing is magnitudes more costly and complicated than using the ones already there.
There are other issues if you start a project using in-house tools
I chose the calculator example because it’s a basic tool yet illustrates the difficulty of a non-standard interface. Sure, anyone can learn it, but learning something only used inside one company limits the career outlook of the employees.
Introducing such tools means:
more retention, especially skilled seniors and early talent(there are studies on who leaves, when company management does stupid things)
harder recruitment (it’s a one-way career path)
more bugs
slower development
higher maintenance cost
lack of standardisation
integration challenges
security risk (the company is alone testing, finding, and mitigating issues)
risk of key personnel leaving
And probably many more.
And yet, we circle back
Sometimes companies already have legacy infrastructure, and that – at first glance – makes it a reasonable choice to start a new project on the same infrastructure/framework so that integration is fast.
Does that make all the problems highlighted above disappear? Obviously not. But refactoring and/or building a new thing is way more time initially.
It is a very hard choice to make, but just think about how much old banks are behind the likes of Revolut in banking experience.
When the time to market cannot be delayed for <insert-random> reasons and a project is in the described situation, I would still advise
implement the MVP using the old tech, but re-implement the whole thing as soon as possible.
Read next:
Programming is nothing else but balancing trade-offs based on project and stakeholder needs.medium.com
Comments