Hacker News new | ask | show | jobs
by ebiester 949 days ago
I can build you a team using today's (quality: average B2B startup) programmers and today's methodologies that will write software for 40 years.

It will just cost twice as much as the team that iterates quickly. It will cost more because I will spend more money on business analysis up front. I will spend more money writing automated tests. Most importantly, I will maintain my own toolchain and libraries or pay someone to do so. Every piece of software deployed will have someone accountable to my business to maintain it.

It turns out that this is expensive. It's no more expensive than maintaining the COBOL code, mind you, and would likely give you better results than the equivalent COBOL code. Most companies will take their chances with less expensive software because that's what their competitors do.

About a decade ago, I saw one of the major systems you talk about up close. While they spent that amount of money for mission-critical systems, they didn't do nearly as good of a job on the average software in the system. I'm not convinced that any business is ready to go back to the battle hardened days.

4 comments

I wonder though whether the up-front costs incurred by your team would eventually be outweighed by the long-term costs of the quick team.
I am not convinced that it would. The quick team will get to learn three times as much and adapt to the actual customer need. The cost of change in a system built with stability as a quality attribute will be higher. (As you can see from a system like the old mainframes!)
The advantage that the original cobol people had is that they had functional manual processes to model.

Today, the payroll supervisor has no idea how many processes work.

Mainframes are expensive because they're niche and basically a duopoly. The companies supplying them know their days are numbered and charge high prices before the market goes dry.

In my experience, the quick teams only learn the surface content. A lack of depth tends to result in more errors down the road and poor architecture. But I guess it doesn't matter since half your team will jump to the next project company in 2-3 years anyways and take that knowledge with them.

> using today's (quality: average B2B startup) programmers and today's methodologies that will write software for 40 years.

I'm not sure I would trust these people over those of the past, regardless of what they say they will accomplish, Chesterton's Fence, and the Lindy Effect, and all.

I imagine that is exactly what:

>spend more money on business analysis up front.

Entails. But sure, if the government doesn't want to pay for that quality, they can spend just as much or more resurrecting Cobol devs in cryo-stasis in 2099

I don't think they have to keep COBOL devs in cryostasis. Some sufficiently motivated individual could likely learn it today. There are even programmers alive right now that would see a large legacy system and not immediately suggest a rewrite on their first day. It's rare but it can happen!
ha! you wouldn’t even be permitted to bid the project!
The trick is to use JS. (Not anything that compiles to it)

It will be guaranteed to run in 100 years time.

Any other language can die or have incompatibility issues. Over that timespan.

I can't tell if I'm being Poe's Law'd. JS engines are a moving target and have been ever since it was called LiveScript.
Just use LISP!
You could use Java or Python and have the same guarantee.

I am not convinced Node will be here in 100 years.

Node might not, but Javascript (even on the server) will mostly be.*

* assuming that the 100 years hyperbole is accepted

Programming languages haven't even been around for 100 years.

There's no guarantee we'll even be running programs written in C in 2123, let alone ones written in JavaScript. 100 years from now is a long time.

> It will be guaranteed to run in 100 years time.

This is never guaranteed. How do you know that nothing will change in JS land in 10 years, much less 100? You don't, that's how.

Brainfuck is the only language we need. It's feature complete and practically guaranteed to go unchanged in the next millenium.