Comment by ut6Ootho | Hacker News Reader

Comment by ut6Ootho | Hacker News Reader

This article certainly rings a bell, as I started rewriting my personal projects to C in the last year, precisely because I wanted to make them decades-proof. I still use the same vimscripts I wrote in early 2000', I want the same thing for all my tooling and apps.

I'm not sure it makes sense professionally, though, as most codebase won't survive a decade : after three years, the dev team will turn over, and the new team will want to rewrite everything from scratch. Or start rewriting parts of the exisiting system in a new language, until it ultimately eat it up. It may be related to the kind of companies I work with, though (very early stage startups).

Regarding interfaces, I think the author could have gone a step further. There is actually a standard and portable interface system: html/js/css. If you write a dependency free web app using things like webcomponents and other standard techs, you know it will stand time, and it actually matches all the reason why the author want to use C : standard and multiple implementations.

It's highly dependent on the domain.

If you're in a web startup, software won't last 3 years, the next team will systematically rewrite.

If you're in the bank, logistics, defense sector, it's very likely the software will go for a decade, as long as it's not killed the first or second year for being a pet project (initial manager left) and having no customer.

> If you're in a web startup, software won't last 3 years, the next team will systematically rewrite.

I have an old man rant about that actually... that rewrite is typically unnecessary if you actually use discipline when developing and learn how to read code.

I once took on a CakePHP 2 app and another developer asked me how in the world I got into, and understood, the framework so quickly. My secret? I read the CakePHP 2 source code. So many developers learn how to do that very well.

> that rewrite is typically unnecessary if you actually use discipline when developing and learn how to read code

"But developers that can exercise discipline and know how to read (and modify) code instead of rewriting cost so much money..." is what you'll typically hear in response to this.

It's cheaper (and often faster) to have cheaper, less disciplined, less experienced developers rewrite something multiple times than it is to have more expensive, more disciplined, more experienced developers write something and maintain it. It's also harder to keep the more experience developers because most developers I work with start looking for another job when their project goes into maintenance.

The typical "we never have enough time/money to do it right the first time but we always have to make the time/money to do it twice" situation.

> It's cheaper (and often faster) to have cheaper, less disciplined, less experienced developers rewrite something multiple times than it is to have more expensive, more disciplined, more experienced developers write something and maintain it.

I can't believe this. I've seen the sheer difference in speed and maintainability a single solid web developer can deliver in a framework they are familiar with versus teams of more Jr developers who spin their wheels for weeks. Rewriting when you don't even understand the starting point is always a waste of money.

> It's also harder to keep the more experience developers because most developers I work with start looking for another job when their project goes into maintenance.

This certainly resonates though. I've been that developer more than once.

> I can't believe this. I've seen the sheer difference in speed and maintainability a single solid web developer can deliver in a framework they are familiar with versus teams of more Jr developers who spin their wheels for weeks. Rewriting when you don't even understand the starting point is always a waste of money.

I agree completely.

It can be quite shocking just how much damage a poor developer can do to small to medium companies. I know of 1 company that's holding on for dear life right now because they lost their biggest client due to a very poor developer they had employed. I told them 6 months before this all happened to get rid of him, but they didn't. And Corona is just making it that much harder for them to find new work.

"I'm not sure it makes sense professionally, though, as most codebase won't survive a decade"

That is highly context sensitive. For example CAD packages are generally decades old.

They can't be rewritten from scratch. There is too much code. Too much of it is domain specific. The features can't change or else customer projects worth billions might suddenly go tits up when they migrate to a newer version (customers don't migrate to newer version very often though).

So, if there is some domain specific use case, worth millions to the software vendor and potentially billions to clients then stability is far more critical than keeping the codebase "modern".

Reply on news.ycombinator.com