At the first client I worked for I once happened to catch one of the lead engineers discuss why he advocated for keeping the business logic separate from pure frontend code. One of the codebases I was involved with was going through a gradual rewrite from Backbone.js to React, and this lead engineer had been in the company working on the frontend since it was founded, so he recounted all the frameworks the frontend had gone through and how the codebases survived all of them, and that “it will survive React too”.
I probably already knew that in the back of my mind, but hearing it spelled out so clearly just as I was starting out was pretty humbling.
What a wise anecdote which matches my experience. I will always prefer well-defined APIs and good backends over uni-stack front-backend-Jacascript-React-cancer.
Yes, all crumbles to ash. Our role in civilization is not to contribute a brick to the great edifice. Culture is a chain reaction that continually renews itself from the old. The old has to be there for the new to come. New technologies can only be created within specific material circumstances, then they displace the circumstances that created them. And maybe a few people found what you made useful for a couple years. Doesn’t mean it was pointless; how many hundred-year-old artifacts do you make use of in everyday life?
Some people in software seems to think they should be building cathedrals, when in fact they’re building the medieval version of a storage shed. It solves an immediate need, it is useful, but is not expected to last for centuries.
The funny thing as I look back is that it’s exactly those things that you desperately want replaced because they are so painful to work on are most often the things that don’t get replaced (or not quickly enough). Often because the application brings in money but rewriting it would be a financial loss to the company, so we just keep duct taping it enough to go on for just a little longer. Funny enough, those are often the applications “inherited” from other companies or ex-colleagues.
I once even had a shitty project like that follow me as I switched jobs(!), simply because nobody was around to understand the application. The problem there was that it was such small amounts of work and in a language my colleagues didn’t know that it wasn’t even worth the time to teach it to new colleagues. Eventually I had to disappoint the customer and say I was no longer going to maintain it.
At the first client I worked for I once happened to catch one of the lead engineers discuss why he advocated for keeping the business logic separate from pure frontend code. One of the codebases I was involved with was going through a gradual rewrite from Backbone.js to React, and this lead engineer had been in the company working on the frontend since it was founded, so he recounted all the frameworks the frontend had gone through and how the codebases survived all of them, and that “it will survive React too”.
I probably already knew that in the back of my mind, but hearing it spelled out so clearly just as I was starting out was pretty humbling.
What a wise anecdote which matches my experience. I will always prefer well-defined APIs and good backends over uni-stack front-backend-Jacascript-React-cancer.
Yes, all crumbles to ash. Our role in civilization is not to contribute a brick to the great edifice. Culture is a chain reaction that continually renews itself from the old. The old has to be there for the new to come. New technologies can only be created within specific material circumstances, then they displace the circumstances that created them. And maybe a few people found what you made useful for a couple years. Doesn’t mean it was pointless; how many hundred-year-old artifacts do you make use of in everyday life?
Some people in software seems to think they should be building cathedrals, when in fact they’re building the medieval version of a storage shed. It solves an immediate need, it is useful, but is not expected to last for centuries.
Hundred year old furniture and housewares aren’t that expensive. Just have to avoid things that contain lead.
The funny thing as I look back is that it’s exactly those things that you desperately want replaced because they are so painful to work on are most often the things that don’t get replaced (or not quickly enough). Often because the application brings in money but rewriting it would be a financial loss to the company, so we just keep duct taping it enough to go on for just a little longer. Funny enough, those are often the applications “inherited” from other companies or ex-colleagues.
I once even had a shitty project like that follow me as I switched jobs(!), simply because nobody was around to understand the application. The problem there was that it was such small amounts of work and in a language my colleagues didn’t know that it wasn’t even worth the time to teach it to new colleagues. Eventually I had to disappoint the customer and say I was no longer going to maintain it.