Hacker News Reader

Comment by ir77 | Hacker News Reader

i'm surprised that people are surprised by this.

i work for aerospace, and this is fairly typical -- albeit not floppy disk examples, but we keep a bunch of old laptops running win 7 and other examples around, hound around for them and spare parts. these machines are off the network, etc.

these systems were developed 20+ years ago and per contract the a manufacture is obligated to maintain them for the service life, so unless these are obsoleted these are to last 20-30+ years.

the costs associated of porting all tools from win 7 to a newer system and re-verifying 50K+ test cases to do a similarity analysis run into astronomical in terms of $ and months (years) of work. no one really wants to poke that bear so you have situations like these.

View on HN

It is interesting that people don't think on these scales. What percentage of the HN crowd has developed something that has had (or will have) a 10, 20 or 40 year life span?

Because I've seen a bit of that and it's what makes the world go round. There's certainly a lot of bad/crazy stuff out there but wonder if the ephemeral fashions of today will stand the tests of time.

Yes, because most people on HN's context is shipping nodejs code.

The best-practices we teach our experimental physics students, whether they know it or not, are generally designed to yield experimental apparatus that can last a decade or more with minimal maintenance.

After you've lived through it, a decade is a very short span of time. If you don't have to think about whether or not something is going to break, you have more free cycles to think about something else that needs doing.

But how would you place that on range between a Sovjet solution and a homemade Minimal Viable Product?

Do you have any materials that you can share about these practices?

I have built applications that have been around for 10 to 15 years.

The only thing that would have been good is to know in advance which ones will last that long - one was a temporary proof of concept!

The jerks always say that it will be 'temporary' and we can redo it later. HAH

This is why at my last job we had a rule that said prototypes could not be shipped as production software. It had to be either completely rewritten, or at least completely code reviewed and the "bad" parts rewritten.

I approach this by writing exploratory prototypes with good modular boundaries, but stub/hacky implementations. Keeping it simple lets me throw modules away as I refactor, until everything's been rewritten and then I ship it.

Sure, and that works great for a personal approach to code. But when your lifecycle from requirements through release needs to be validated, something more scalable is required. Sometimes that scalable thing is "anyone shipping prototype code will be fired."

It seems like no matter the industry, a (good) temporary fix becomes a permanent solution.

We never have the money to do it right the first time, instead we always find the money to do it a second time.

Some code I wrote in a drunken haze has been running continuously for 7 years with zero downtime - it was only meant to be temporary!

It has zero comments, the code was inefficient, the variable names are things like "theThing" (it's the best I could do at the time) and "database" is just a series of text files carefully read/written to on the disk.

In my first job we did project/information management systems. Initially for civil engineering projects, later more generally for governments and enterprises.

In some cases we had to have contingency plans for the software and data in case the company goes out of business within the coming 15 years.

Next I worked in advertisement, where clients spent similar sums as the above for cross media campaigns lasting maybe 14 days

That was quite the interesting contrast work wise :)

Whatever the average age of the HN crowd is would probably inform a little. I'm 34 and have been a dev for about 8 years. The only code from a past job that I know for a fact is still in use today is something that I wrote in early 2017 (a let's encrypt integration for a web host). So about three years. I'm very curious to know how it has been updated since but I'm no longer at that job.

Not a single comment in this comment section seems surprised by this - so probably a large percentage.

Self selection bias surely doesn't apply to software developers.

True of course. I just found the contrast between "people don't think in those scales" and the comment section interesting - and generally think that a surprising amount of code survives for a decade or more.

> What percentage of the HN crowd has developed something that has had (or will have) a 10, 20 or 40 year life span?

I'm also curious about the work/personal split here. I have a small handful of things at home I first wrote around 10-12 years ago that I still use and tweak, but have only been working professionally for about 9 years (and have worked on things in that time I personally fully expect to hit 20-30 years).

I'm in my 30s, I've been a primarily web developer for 15 years, and I know there is software I wrote in 2008 that is still running today for processing the rent of 1000s of residents. It has been updated a few times, adding a console argument to automate the process more. It was originally a Bob-O-Matic process. At midnight on the first of the month, this old-timer Bob would launch the application, click one button to load the residents, double check the numbers, click another the button to pull the rent statements, check those numbers, and then click a third button to process the transactions which actually took about an hour to run through, and on occasion would actually crash once a year or so, but it had the ability to pick back up after a crash where it left off.

That was probably my first real bit of production code, it (un)fortunately replaced half a floor of people with one man, who faithfully clicked those buttons every first midnight for the next 10 years before he retired. It was then automated by the couple of South African contractors that replaced the NYC-based app development team.

The company spent about 12 years automating away almost every job except management.

Sounds like a nice, no-frills tool that does its job!

It was meant to be a temporary solution until the online payments module was developed by the vendor. Yet, here we are in 2020 and that module still hasn't been delivered. And no one who worked there initially is even around any longer.

If I'm not mistaken, we even gave them our code back in 2009 or 2010.

"A good temporary fix will become a permanent solution" :D

Software Engineering Life Pro Tip:

s/for now/forever

I built a relatively simple system over 10 years ago that ran on PHP and MySQL. Over the years, the company I built the product for has come back to me to upgrade PHP and MySQL after a security scan. The problem is the software was build for PHP 5.4, and they want it running on the latest (7.4). It doesn't.

I managed to get it running on the latest security release of 7.1 with a few days of work (I had to make code changes in the framework I used that weren't supported in PHP 7 anymore). If they want future security upgrades, it's going to require a even more significant rewrite of the software because it relies on old PHP behaviours that have been removed in recent releases.

So, I completely understand why 20 year old systems would still rely on floppy disks.

I charge my proofreaders a euro every time they miss 'built' spelled as 'built'. It's been a pretty steady money maker, that one. I make a ton of spelling errors as well so who am I to cast that particular stone but the built-with-a-t one seems particular hard to get rid of even when you know about it.

Must be some cognitive blind spot.

> 'built' spelled as 'built'

Did autocorrect “fix” your intentional misspelling for you?

>Must be some cognitive blind spot.

Hehe, yeah for the better or the worst ;)

I built an invoicing / international shipment documentation generation / stock control / production tracking system with Excel and VBA and it's been in production for close to 20 years! I am conflicted as to whether or not I should be proud of that. ;)

Like the parent poster, I've shipped systems that have to be in production and supported for 20+ years, so this isn't surprising.

That said, most of my career has been in embedded systems, so this kind of lifetime isn't really unusual.

I wrote a piece of software that still handles all engineering project management for one of the larger communications companies in North America (>2.5 million customers). I developed it in 1997 and it is still in place today, chugging away for ~400 daily users and getting minor updates a couple times a year. I didn't remotely think it would last on this timescale and I have paid the price for some poor design decisions many times over. Still, as much as I cringe at some of the older sections of code, it has been nice to see it keep going.

The client has started internal projects to replace it 3x over and each has been cancelled; sum total spent on the cancelled projects easily exceeds what I charged by an order of magnitude. In retrospect I didn't charge nearly enough back then! If only I could have used a SAAS model.

A slightly different spin has been working on some 20+ year old C/C++ code that is relatively nicely written, such that you can still expand on it today.

I had a lot of joy recently reading the Voyager 1 image decompression routines and some X11 window manager sources.

> What percentage of the HN crowd has developed something that has had (or will have) a 10, 20 or 40 year life span?

The backend of the dmd D compiler was originally developed in 1983. Of course, it's been through a lot of dramatic changes.

> It is interesting that people don't think on these scales. What percentage of the HN crowd has developed something that has had (or will have) a 10, 20 or 40 year life span?

> Because I've seen a bit of that and it's what makes the world go round. There's certainly a lot of bad/crazy stuff out there but wonder if the ephemeral fashions of today will stand the tests of time.

Not many, I'd wager. I've even seem a few people argue here (IIRC) that backwards compatibility is an antipattern, which is the thing that allows systems to function on scales longer than an ephemeral fashion.

I have stuff I wrote 15 years ago still in daily use from 500+ people to produce news which is seen by tens (hundreds?) of millions of people, last serious development on it was 2012, written in perl of course. Another system a colleague wrote from the same time, written in PHP, looks after image archives. I don't believe that's changed much either.

There's a lot of infrastructure stuff that dates back 12 years, when we standardised the entire place on ubuntu (804) for linux (and got rid of solaris at the same time).

That's all fairly new though. A lot of broadcast equipment still in use store config on 3.5" floppy disks, and I saw a windows 3.1 machine still running in a branch office about 18 months ago.

Some stuff I wrote in the 80's is still up and running.

>>> What percentage of the HN crowd has developed something that has had (or will have) a 10, 20 or 40 year life span?

Did that a lot when I was working at a major US bank (JP Morgan). All the critical software I worked on was planned for 10-20 years in my mind. Some of the work was upgrading/rewriting ancient things that have been there for 15 years, sometimes mostly untouched. Wrote some blog posts about it.

The most remarkable legacy system I have seen : That one was 13 years old, upgraded and half rewritten with bug to bug compatibility, 99% sure it will still be there in 13 years. https://thehftguy.com/2020/07/09/the-most-remarkable-legacy-...

Retired the last Perl software in the bank, rewrote in python and made sure it works on 2.6 and 2.7 and 3.7 to cover the upcoming decade. That software was handling in the order of a trillion dollars per day, wouldn't be surprised if it's still there in 30 years. https://thehftguy.com/2020/06/26/are-banks-still-using-perl-...

I once worked on a project that made me think that year 2038 will be interesting for the military.

I used to work for a manufacturers that had industrial equipment that was 15 years old. We had 15 year old PCs to talk to it. That was about 20 years ago. From what I hear, they’re using the same equipment, and same PCs.

35 years means they must be using 286s to run that stuff. On the plus side, nothing requires fans, the motherboards are extremely simple (albeit a mess of logic chips), and your biggest worry is probably the power supply. Right?

I dunno. I could easily see taking decently made hardware to the 20 year mark.

I've written PLC code in the 90's which still runs today.

It's not ephemeral - when you think about upgrade cycles and deprecation of tech.

What I would claim - is that people who targeted Win95 for equipment that had to last decades never bothered to understand how software ecosystem works. They just "threw it together"...

That said - the floppy disks isn't that bad, per se. I would have expected Boeing to be smart enough to expose a data loading interface, that can read something "as if it was a floppy disk"... But then I look af 737 and Boeing's failure to deliver a crew space launch vehicle - and get reminded that they only exist because US government literally props it up.

MS is extending extending free Windows 7 security updates to voting systems so that the US can get trough 2020 elections.

There is still Itanium hardware running on Windows Server 2008 R2 (Same Kernel as Win 7) and it's supported until at least 2025.

Safety critical and big enterprise software contracts are often written to keep the system running and updated with minimal changes and cost "Until the iron gets tired".

Perhaps people are surprised sometimes by how amazing maintenance and reliability engineering in the field really is. A small example like having these machines use a medium which some of the younger crew haven't even heard of is a nice reminder of this. Sure maintaining backwards-compatibility has a cost, but so does constantly rewriting everything that already works.

I worry how companies will be able to provide similar services in the future, as more and more stuff is running as services in the cloud.

It’ll most likely become more and more costly, as you won’t be able to buy offline version of some complement, and keep it working on your support device for 30 years. You’ll need to build all of them yourself. And that will also most likely mean it’ll be less reliable.

People will just build new airplanes every 6 weeks when a new rustc is released. Economic growth has to come from somewhere...

Lol. Aircraft software running "in the cloud". Damb right it will. It will also work "in the rain" and "in the snow".

Is "Snow computing" when everything freezes up?

The maintenance and logistics software for the F35 is supposedly implemented with a cloud architecture. Though the project is probably old enough that the cloud hasn't found its way into the flight systems yet...

Then you "just" don't use those services. It's not rocket science ...ok sometimes it literally is... but part of reliability engineering is knowing where your weak points are and preventing them from causing problems before it happens. Since the default state is building it yourself, not being able to buy an offline version of the service is no less reliable than the alternative.

Default state is never building it yourself. When you approach new problem, you don't go "ok, let's first start a fire, then melt some silicon to build me some transistors". You always start based on something. And as more stuff is moving to be cloud based services, you'll need to build more and more of that stuff yourself.

Taking it to the extreme - will CPUs in 30 years be cloud connected and require my service provider to work? Would OS be? Or scheduler? Or terminal? Or dynamic linker for libraries? Or IPC framework?

How much of that stuff will companies need to build in the future themselves? It's not like software will get simpler, so they won't need it.

Changing your assumption of "default state" doesn't change what I said.

The point is that systems like this go through various analyses before being built. Reliance on outside services/components is one of those analyses.

Let's say that a critical component is an online service. Someone will do the analysis of what happens when that service goes away. If the outcome is that you can expect to failover to something else with acceptable degradation of performance, then the service might be used. If not, then the choice is find a more reliable service, build it yourself or do without the feature. And those last two choices will themselves be subject to another analysis.

One of the nice things about capitalism is that if there's a profitable gap in products/services, that gap will eventually be filled. All new CPUs need to cloud connected and require a service provider, but there's a big industry that can't deal with that? I guarantee that someone will corner that market and start building CPUs that don't need to be cloud connected and require a service provider. Either that, or sufficiently reliable cloud services, tailored to that market, will appear.

You seem to forget about economy of scale. Sure, void will be filled, but you'll get worse, and more expensive solutions. Economy of scale is ruthless.

And this isn't only talking about software you put on the devices. Developer environment is going to degrade even more and more. It's already bad experience to develop stuff for things that need long term support, and with cloud trends, it'll only get worse, as set of tools that you could possibly use will reduce.

I've spent basically my entire career working on systems that need long-term support and my experience indicates otherwise.

Have you tried working on the other side of the fence? I did work in both areas and differences are huge.

>> we keep a bunch of old laptops running win 7

I guess I was thinking laptops running DOS, like the ones used to interface with the Mclaren F1 (supercar) computer.

> i'm surprised that people are surprised by this.

While I'm not surprised per se (seen it enough here and in the industry), it does make me sad and worried about the industry.

This short-term thinking is starting to break everything. How many things sold today depend on some smartphone app? What is the chance that said app will be available or able to run in ten years? Thirty years? I'll bet big money on zero percent chance.

Wouldn't modernizing things here and there not also mean that at some point the entire airplane has to go trough the approval processes again because it is now no longer considered a 747 which in turn also means all personnel need to be certified for the new type?

I once heard, that is the reason why many airplanes still have a "no smoking" light switch in the cockpit although it does not do anything anymore.

Google could never maintain an airplane.

Definitely not, but they could probably convince the public that the reason their airplanes kept crashing was one of their competitors.

And SpaceX did blow up a spaceship for human flight where they didn’t expect it to.

The teams they buy could!

There's probably a few very widely depended-on libraries in google3 (internal monorepo) that have been in 'maintenance mode' for 10y or more.

And pretty major pieces that get replaced with nothing breaking noticeably.

A better analogy would be like swapping the engines for electric drive props mid-flight, while other team is replacing most of the wings, but keeping the control surfaces in place.

Now, the cargo service would've been killed, and you'd have 3 mostly equivalent screens to choose from to watch movies during your flight.

> we keep a bunch of old laptops running win 7 and other examples around, hound around for them and spare parts

Maybe I misunderstood something, but do you really need some specific, old hardware to run win 7? I thought you are going to say DOS or something older than win 98.

Why don't you run your old system in a vm running in a new system? That is standard practice at some places. Was there special hardware, not just say usb ports?

Why not just virtualize it and use whatever hardware you want?

The hardware itself may be the issue. Even com ports over usb don't work a good amount of the time

Yes. I do some DoD Aerospace work, and we have expensive PCI cards that only work on Windows 7 or XP that are used to talk MIL-1553B to our hardware. So, we've got to have a piece of hardware that can handle both of requirements which can be a pain.

The hardware probably has to be tested just the same. I don't think that gets you anything, except more complexity and more testing.

That says more about "the bear", and the overbearing nature of the compliance process, then it does about the wisdom or foolishness of relying on an aging hardware platform like the floppy more generally. Most industries don't deal with that. Maybe if this process had actually proved sufficient to prevent the 737 Max woes, we would pay it more respect?

Arguably the 737 Max disaster was caused by an attempt to side step the regulatory process and get a new plane certified when it shouldn’t have. If the FAA hadn’t been so captured by Boeing, those two planes wouldn’t have crashed.

All in all I can’t understand how one can look at the state of the airline manufacturing in the past 50 years and decide that less regulation is needed. Except for the MAX 8, phenomenal gains in airline safety have been gained over this time period, throwing all that away so that it’s easier to upgrade some old hardware seems incredibly foolish.

> how one can look at the state of the airline manufacturing in the past 50 years and decide that less regulation is needed

Less regulation = rich founder kids gets lambos + utter destruction of society = good :thumbsup:

> Maybe if this process had actually proved sufficient to prevent the 737 Max woes, we would pay it more respect?

A better measure is passenger deaths per kilometer.

https://commons.wikimedia.org/wiki/File:Fatalities_per_reven...

It's been on a steady, large decline since the 1970s. Even with the 737 MAX crashes, it's an incredibly safe way to travel.

In the last ten years, one passenger has died on a US carrier due to an aircraft issue. (https://en.wikipedia.org/wiki/Southwest_Airlines_Flight_1380)

just want to call out -

  The engine literally exploded, and they made it home via the rest of the plane OK (minus the unfortunate passenger).

In the past this would have cut hydrolics (this happened with a DC10 rear engine exploding) and then losing control. Major props to the pilots and boeing (all SW planes are 737s I believe).

Yes, Southwest only flies 737s in order to simplify their maintenance logistics and to ensure that every pilot they have can fly every plane.

The 737 Max grounding cost about $18 billion so far (according tot he Google infobox which knows everything and is never wrong.) The high-end estimates of the value of a statistical human life tend to run about $4-8 million, depending who you ask. The FAA grounding of the Max has 2250 has thus cost enough money to save 2,250-4,500 statistical lives, had the money been spent more wisely elsewhere.

How does your "better" passenger-deaths-per-km measure account for these deaths? (And what is it superior to, exactly?)

You can't point to the grounding of the 737 Max 8 as a reliable indicator of the cost of regulation because:

1. Arguably this is the cost of regulations not being followed properly

2. This is an extra-ordinary circumstance that is costing much more than a regular plane would cost to get certified and fly (see point 1)

3. You are drastically underestimating the cost to the industry both in terms of reduced customer confidence, hull losses (~$100mil an airplane), and increased insurance premiums if we were to continue flying the Max 8.

But honestly, I'm having a really hard time understanding what your point is. Are you asserting that we should just fly the Max 8 and not worry about it? Are you asserting that airplanes aren't safer now? What are you getting at?

> (And what is it superior to, exactly?)

Pretty much any other form of transit, safety-wise.

https://en.wikipedia.org/wiki/Aviation_safety#United_States

> The number of deaths per passenger-mile on commercial airlines in the United States between 2000 and 2010 was about 0.2 deaths per 10 billion passenger-miles. For driving, the rate was 150 per 10 billion vehicle-miles for 2000 : 750 times higher per mile than for flying in a commercial airplane.

> How does your "better" passenger-deaths-per-km measure account for these deaths?

You propose a silly metric. Car accidents cost $871 billion a year. https://www.pbs.org/newshour/nation/motor-vehicle-crashes-u-...

You are severely underestimating how few air disasters we've had lately. The DC10 had an abysmal track record.

Airplane engines literally flying off the plane during takeoff because the airlines got to do whatever they wanted for servicing it instead of the recommended method because maintenance time.

https://en.wikipedia.org/wiki/American_Airlines_Flight_191

Boeing and Airbus and CRJ/Bombadier/NowAirbus have done a -really- friggin good job in the past 2 decades.

Why the hell would they need to upgrade something as non-essential as a floppy system? To What? Why does it matter if it works? Introducing uncertainty to a system to just make it "new" is spoken like a web dev and not like an aerospace engineer (and I'm a web dev).

In node land you get blasted if you don't stay current (because something will rely on something newer and you'll get upgrade hell'd at once instead of piecemeal).

There are no new versions of GQL that people need to upgrade to. Nor is their version of node going off LTS in 2 years.

Reply on news.ycombinator.com