[maxxxxx]

A lot of young people think that the people who wrote software 30 years ago were just plain stupid and all wrote crappy code. In reality there were people back then who did a good job and there were people who didn’t. They just used different tools. I can’t wait for the current systems to become 30 years old. Making changes to micro services architectures written in different languages over multiple servers will be a lot of fun.

[roymurdock]

Necessity is the mother of invention and memory/resource scarcity is the mother of quality code

A lot of junk and spaghetti code gets written (or copied/pasted together) today because there are few hardware-based constraints in much of modern app and system dev

I work with a lot of embedded engineers and have the utmost respect for those that work on safety-critical, legacy systems

[carrigan]

I don't believe that hardware constraints have anything to do with code quality. Running your code on a microcontroller will require your algorithms to run in a smaller RAM footprint and potentially come with timing requirements, but do not dictate that you write quality code to do so. You can solve those problems with thousands of lines of uncommented assembly efficiently, but that does not mean it is quality code.

I have worked for a significant time in my career as both an embedded engineer as well as a backend engineer, and in general I find that the backend code is way easier to read, maintain, and extend. Embedded code is seldom properly tested and most of it is written in C where people can abuse a library's contracts or the preprocessor. It is not uncommon to find functions that are over a thousand lines in the embedded world. Compare this to Rails where there are a ton of standards, short and succinct functions, and good support for testing.

I guess it depends on your definition of "quality code". If you mean code that is dependable and will do one thing well on one platform for the rest of time, then embedded code could be considered high quality. I would debate that these items have more to do with the binary than the code though. If you mean code that conveys how a program works well to other programmers, is under test, and follows some standard structure, I would pick modern app development as typically being much higher quality.

[pjc50]

I don't know where this got a downvote from because it's correct - it's quite hard to build sensible automatic integration tests for embedded code unless you have the luxury of a full system emulation.

The only thing that resource constraint forces is less code, especially less dependencies, because you run out of space.

The Toyota "unintended acceleration" court case was a flagship example of bad embedded code, that we rarely get to see.

[jacobush]

The Toyota computer is like a super computer compared to old mainframes. IIRC the Toyota program had 10k global variables updated by spaghetti C code. So you had a lot of space, enough to shoot yourself with C code. Old mainframe code in contrast often operated on records in a batch fashion, with a pretty clear input and output.

Of course, the antipattern on enterprise code comparable to thousands of global variables in C code, is to have thousands of columns in hundreds, or thousands even, of database tables, all intertwined and used only God knows where.

[monocasa]

AFAIR, the were also autogenning code from a Matlab model of the engine, and that's where the 10k globals thing is from. Like yeah there's technically C code that's doing that, but come on.

[freedomben]

Interesting, I thought the "unintended acceleration" was actually just floor mats creeping up and holding the accelerator pedal. Gonna have to google some stuff now :-)

[pjc50]

https://news.ycombinator.com/item?id=9643204

It's one of those Rashomon situations where I'm not sure we can ever be entirely sure but it seems to have stopped.

[jackalo]

Thank you for linking that. The comments in it share some terrifying stories.

[ambicapter]

That was Toyota's explanation for what was happening. Turned out to be a lie or a hasty conclusion, I don't remember which.

[rbanffy]

> I don't believe that hardware constraints have anything to do with code quality.

When the punishment for writing code that doesn't work is a long wait, you learn to write small pieces and test individually.

[drabiega]

> memory/resource scarcity is the mother of quality code

My experience with Legacy code has been the exact opposite of this. I've seen some really well written and documented legacy code but almost never in resource / performance sensitive areas.

People inevitably seem to accept trade-offs that sacrifice readability and maintainability for efficiency.

[C1sc0cat]

Well I recall writing Fortan 77 for a billing system and we had nicely structured code (our team leader was a genius) but we did do some specific stuff eg reading in data in chunks the size of a disk sector.

[maxxxxx]

And it was perfectly normal to do stuff like this.

[Pamar]

Canonical example: https://en.m.wikipedia.org/wiki/The_Story_of_Mel

[emiliobumachar]

"resource scarcity is the mother of quality code"

I don't know, your mileage may vary with this one. I have had to make code less readable to make it more efficient more often than I've been forced to find a more elegant way because the clever hack was too slow.

[bbatha]

I wish that were true. I’ve worked on a lot of old FORTRAN code bases (including a couple that started life as punch cards) and it just doesn’t bear out. Remember FORTRAN comes from an era we’re people we’re concerned about the overhead of a function call. Programmers also worried about he memory overhead of comments in their editor! Most FORTRAN is a mess of gotos, common blocks, implicit types and other relics that should be left to the past. This code doesn’t age well either, optimizers don’t do well with gotos and the lack of function calls means that there are copy and pasted snippets of what my coworkers and I called “fassembly” that were untranslatable. One time I spent days translating one of these functions only to realize that it was an fft, I swapped it out with one from a library that had be optimized for decades the code was easier to read and 100x faster. I’m not even going to discuss any code base that was unfortunate to need any kind of string manipulation. To cap it off FORTRAN 77 doesn’t even allow variables with names longer than six characters.

That all said, modern FORTRAN is entirely pleasant language. Just stay away from the legacy.

[SilasX]

>A lot of junk and spaghetti code gets written (or copied/pasted together) today because there are few hardware-based constraints in much of modern app and system dev

Maybe in the general case, but there are so many exceptions they're almost the rule. Apps like JIRA and Electron constantly have slowdown from bloat that pretty clearly is swamping the hardware constraints and would be avoided with better coding.

Also, I see classic games that are emulated or transformed on "fast" hardware that nevertheless have input lag. I've seen this one the Wii console for SNES games, and on inflight emulator that ran Pac-Man. Plus, TVs that upscale make Dance Dance Revolution have too much lag to be playable.

[tzs]

> I can’t wait for the current systems to become 30 years old. Making changes to micro services architectures written in different languages over multiple servers will be a lot of fun.

This will be bad even if they are all written in the same language, if they were not also all written in the same time frame.

With ancient FORTRAN systems, generally you need to learn the version of FORTRAN it was written in (FORTRAN 77, Fortran 90, etc) and enough about the problem domain to understand what they were trying to do.

With the kind of systems we are making now the hapless maintainer will not only have have to learn the specific ancient language version and the problem domain, but also whatever now forgotten framework was in fashion at the time the thing was written.

[elicash]

The stereotype isn't that the code was bad -- it's around the UI. (There are also stereotypes around modern UI being too minimalistic. Obviously these things are not so simple.)

There's also the idea NOT that it was bad when it was written 30 years ago, but that 30 years of patches by people who didn't write the original code mean it's no longer clean code.

[thisisit]

Early in my career I worked on legacy i-Series systems. One of things we were taught was to never write a code without putting in comments in the header. And the commends need to specify dates, ticket number for tracking, and the rationale behind the change. Every changed line had to be inside a block with the same ticket number, making it easier to simply Ctrl+F through the code.

Now I work on newer software and I frequently see people making changes without spelling out the rationale, dates, author etc. And it makes it harder to track what has happened and what does the code do exactly. When I tell people to comment it correctly they often reply about - how much time saving can be had by writing a clean code.

[fwip]

Nowadays we keep that information in the VCS. git blame gives you more reliable info than careful comments (assuming that the rationale is recorded in the commit message).

[lostcolony]

Integrate with a ticketing system, force commits to match a pattern, and you can ensure the rationale is tied to your ticketing system (i.e., commits/merges have to be prefaced with FOO-####)

[klardotsh]

This is generally great (and I do it on projects I'm confident won't be moving any time in their useful life), but if you ever switch VCS/ticket systems, it gets messy quick.

Ever moved from Github Issues to Jira/Trello or vice-versa? How about Bitbucket to Github (as I did for my current company)? That's a whole lot of context potentially being lost, either in tickets or PR discussions.

How much of that lost context would have ever been used anyway is up for debate, of course. In my experience the answer tends to be "rarely, but sometimes".

[sedachv]

This is why I discourage Free Software projects from using hosted issue trackers entirely, especially ones that are proprietary (such as GitHub). Mailing lists are the best solution for longevity and meaningful discussion. If you really need to, you can organize things in a file that is in the repository alongside the source code (Org mode is great for this), which has many significant advantages (and downsides, like not being point-click for PMs, but if your Free Software project has PMs, you have bigger problems that software cannot solve).

[james_s_tayler]

Often that sometimes is a life saver though...

[pcnix]

This happens on github/gitlab too, with pretty much all open source projects. It's definitely a cause for concern eventually, because the context for the problem and the rationale for decisions is now something that you have to maintain apart from just maintaining the codebase. Right now github etc do a good job of managing that for you, but the long term handling of this context definitely has scope to improve.

[maxxxxx]

Obviously this system will be obsolete in a few years too and nobody will know how to find stuff int it :-)

[james_s_tayler]

Well you know my last job I worked on a system that was a lot of 4gl under the hood and a Java application that sat on top calling the legacy 4gl code. The 4gl code had comments in the header with dates and ticket numbers. The dates stated late 80s and 90s. The ticket system was from 4 ticket systems ago so that was useless. The comments had become wrong over a period of 30 years of changes. The rationale for something in 1989 made a lot less sense for 2015. The author was now the boss for the whole office and hadn't touched code in 25 years so I can't go ask him about this function he wrote in 1989.

Entropy. It's not our friend. It's why we can't have nice things. Code bases suffer from bit-rot over time.

[FiddlyPack]

I think all of things you mention have value, but all of that information is (and in my setup, displayed inline) located in git. We keep ticketing, author, rational, and version changes, and you can walk through the changes with the tracked intentionality by stepping back through the version control.

[southern_cross]

I followed a similar protocol, but then I ran into a situation where good discipline kind of went out the window during "the great outsourcing". So when recently updated code had problems, because my info was the last actually properly recorded in the source code (even though I hadn't touched that code in years), someone might come gunning for me to fix the problems with "my" code. Not fun, especially when I might actually take a look at that code and see how badly the outsourced folks had mangled it!

[WrtCdEvrydy]

Build the UI for the target user.

Minimalistic UIs are great if you're trying to make it simpler for outsiders.

If you have people who understand how to use the software, you can actually cram the UI full of everything you need in a single place.

[jklinger410]

Look, this sounds like you are talking about brutalist design for corporate software, and I can dig that.

What I can not dig is how old software prints things to screen. Touch a new dimension, let's recompile the data and re-load the list/entire screen right now! We've never done analytics our study our user base, so the most popular functions are buried 10 levels deep in a menu that re-loads every time you lose your scroll spot! ETC.

If you have spent time in corporate software developed in the WIN 95 days (cough oracle CRM cough) you won't see intentionally brutalist design. You will often see Magyver level hacks stacked through the roof, and software that loads so slowly you can re-load Gmail 3 times before it finishes.

[ams6110]

First generations of browser-based UI did refresh/reload the page a lot. But there was nothing else they could do, really. AJAX wasn't a thing, DOM manipulation wasn't possible.

Older UIs written in Visual Basic, Delphi, Powerbuilder, or even for text-mode interfaces did not do this, because the frameworks supported refreshing only the changed data.

Look at how emacs or vi works over a 1200 baud dial-up connection. Surprise, it does, because it only redraws the parts of the screen that are changed. These problems were solved in the 1970s and 1980s.

The web broswer has been for most of its existence a really bad way to deliver user interfaces. The zero-deploy nature of it was very powerful though, so people suffered through it. Only in the last few years have browser-based interfaces approached the abilities of native clients.

[maxxxxx]

“you can re-load Gmail 3 times before it finishes.”

After the latest changea to Gmail I have high hopes that it soon will catch up in terms of slowness :)

[maxxxxx]

Most UIs these days seem written for beginners. Easy to get in but they become tedious for experienced people.

[sli]

Oof. Currently developing software for doctors to use and this feels all too real. The concessions we have to make to cater to their relative inability to adapt would make me hate using this UI every day, but it's what they want.

It's not like I don't get it. I do. Just not 100% of the time.

[basch]

eg Facebook or Amazon or Outlook or Photoshop. The antithesis of minimalism, features and buttons everywhere.

[EpicEng]

>Making changes to micro services architectures written in different languages over multiple servers will be a lot of fun.

Don't forget the 10,000 packages you need to find because they no longer have a feed available! They'll be rewrites.

[baldfat]

> A lot of young people think that the people who wrote software 30 years ago were just plain stupid and all wrote crappy code.

The generation from the 70s and 80s will forever be the best technological generation the world will ever see. We had serious constraints that would need elegant solutions. I remember as a kid looking at Z80 maunals to learn how to save a few bytes so that code would run, or the 680k Microsoft limit that caused the code to be very concise and every bit was thoughtfully used.

Now that the sky is the limit we have cookie cutter solutions built on other pieces that "work" which really are just rewritten code in some new language or framework. This is now the new norm and it will never change.

[zbentley]

> We had serious constraints that would need elegant solutions.

In the era of abundant hardware resources, I like to think that this sense of craftsmanship hasn't been abandoned, but rather transmuted--transmuted into the ability to make things as readable, accessible, and maintainable as possible.

The Redis, Phantom (Thrift proxy), Kafka, and PostgreSQL codebases are regularly things I consult as role models in the design of clean, pragmatic code.

The explosion of technologies since the elegance-by-necessity-of-optimization era does not necessarily mean that the capability of engineers has declined.

[bitexploder]

As a generation yes. But, I got started in 93/94, learned C. Got into infosec and reversing and can do machine code reasonably well these days. Plenty of my peers learned assembly on TI calculators and other places. By the numbers there are probably more competent low level systems engineers then there were in the 70s and 80s. As a ratio of programming professionals we are dwarfed by PHP programmers, etc.

[majkinetor]

> We had serious constraints that would need elegant solutions

I don't think those are comparable to complexities in IT that exist today.

[dragonwriter]

> I don't think those are comparable to complexities in IT that exist today.

I think the constraints and lack of “here you go” resources many starting programmers dealt with, even for toy applications, out of necessity in the 70s and 80s are better preparation for the attitude necessary for dealing with the complexities in IT today than the learning conditions today.

Which isn't to idealize it, it was also a hard onramp that drove lots of people off that would have done well at many real world problems where they weren't soloing without support, and night with experience have still developed to great solo practitioners, too. But the people I've encountered that came through that 70s/80s start tend to be, IME, on average more willing to slog through and learn hard stuff in new areas than people who came up through, later, easier onramps.

Though that may also be in significant part survivorship bias, as the 70s/80s crew will have had to have stuck around the field longer, usually, and it may be people with that flexibility are more likely to stay in technology past the half-life of whatever was current when they got in.

[driverdan]

In business the goal of software is to make money. Elegant solutions do not necessary increase the bottom line. Increasing productivity at the cost of elegance is a net win in most cases.

[flukus]

And yet I've seen plenty of business spend a huge amount of time and effort on "enterprise" abominations to attempt to build elegant extensible systems. I've seen at least a dozen instances of cron businesses re-invented. I've seen business throw money down bottomless holes on proprietary databases. There's a well known tech company that now owns two bloated electron based cross platform text editors, neither ever had the goal of making money, at least directly.

Business is great at wasting money on software, I just wish they'd waste it in a way that benefited people.

[sandworm101]

Survivor bias. The fortran that is still running is the elegant stuff, the stuff that was written well enough that nobody has needed to touch it for decades. Just as with "classic" cars, there was plenty of junk out there at the time. What is left is the most resilient, not necessarily representative of the whole.

[fixermark]

It is entirely possible that one could make the assumption that if software was written 40 years ago and hasn't yet been rewritten, that it's good enough as-is that it survived the test of time.

[scarejunba]

Or that it is so horrendous as to be untouchable.

[rbanffy]

May be horrendous, but still does the job.

[WalterBright]

> A lot of young people think that the people who wrote software 30 years ago were just plain stupid and all wrote crappy code.

Stupid, no. Crappy code, yes. Part of the reason people wrote crappy code then is because programming techniques and best practices have come a long way. The other part is most people writing code then were inexperienced coders.

Of course, plenty of crappy code (most?) is written today, mostly because of inexperienced coders. It's not because they're stupid. After all, who would make a 20 year old a general?

[james_s_tayler]

Thinking about it as 'crappy code' is the wrong way to think about it. It's average code. Everything is normally distributed, including the quality of code. On average code quality is average. Some of it at the top tail end of the distribution is beautiful and some of it at the bottom end is an unworkable trash fire.

That hasn't change in the last few decades and it won't change in the next few decades either.

[EamonnMR]

We've already reached the "fun" point for legacy Rails apps.

[rapind]

I have no issues navigating around in an old rails 1.2 app. The problem is usually the special sauce and anti-patterns that have been added to it over the years. This is a problem regardless of language or framework.

[benbristow]

Running a Rails 1.2 app sounds... dangerous. Have you plans on upgrading it? (Probably at this point easier to start a fresh Rails 5 app, write some tests + copy/edit stuff over as needed).

[notduncansmith]

Thankfully, most of those won't survive for 30 years. Anything that lasts that long without constant maintenance is probably a well-designed system that you won't mind working on.

[Dirlewanger]

It seems like with the modern pace of software today, things are practically guaranteed a rewrite within 5 years.

[blihp]

We said the same thing back then too.

[bachmeier]

A lot of developers using [insert this week's hot framework] think that the people who wrote software 30 days ago were just plain stupid and all wrote crappy code because they were using [insert the hot framework of four weeks back].

[potta_coffee]

It's already "fun" trying to maintain systems that are two years old.

[boznz]

>I can’t wait for the current systems to become 30 years old.

Good luck with them lasting 10 years

[maxxxxx]

That has been the fallacy for a long time. I remember discussions in the 90s when I asked people why we didn't store 4 digits for years and I was told "By 2000 this will already have been replaced". I know for sure that this particular system was still used in 2010 and probably even now. things that work keep getting used.

[sharpy]

Yep. Software can last surprisingly long time. Personally wrote a micro service with intended life-time of 6 months. 8 years on, it is still soldering on, surviving multiple attempts to replace it, with almost zero maintenance.

[NeedMoreTea]

At least there was some justification for space saving in the 60s when your PDP8 gave 4k core memory. Probably not unreasonable to expect the code to be obsolete by y2k either.

[maxxxxx]

In the 90s that use case was not valid anymore but the mindset still persisted.

[NeedMoreTea]

Very true. I was probably guilty myself - everyone was expected to know how structures aligned, and how to pack, so "being efficient" was often just thought part of writing good code. Hopefully there weren't so many 2 digit dates being coded in the 90s though. :)

It was probably still a valid use case for comms, if not within the application. Code was still being built on x25 and oh-so-slow modem links.

[ams6110]

There was a lot of 2-digit year coded in the early 1990s. I wrote some of it myself. The reason was compatibility with older code/data formats, and also as mentioned the notion that "this will all be gone before 2000" or that it would be updated along with everything else if it had to be.

[mathattack]

Same as today. If anything, programming was accessible to fewer people back in the day. What looks like poor design decisions today (fixed length integers) was just a reality they had to deal with.

[rbanffy]

> and all wrote crappy code

Yet, we didn't hear about left-pad until what? 2016?

[TheGRS]

Maybe some do, but I look at the past coding era as more of a mystical age where wizards and gurus made things happen out of thin air. Seems pretty impressive to me.

[dv_dt]

They also got a lot more time to think about more focused problems because many aspects of compute complexity simply weren’t possible

[908087]

> young people think that the people who wrote software 30 years ago were just plain stupid and all wrote crappy code.

It's understandable. None of us back then had anywhere near the "copying and pasting javascript from stackexchange" skills that "tech savvy" kids have now.

[51lver]

There's also a disposable culture around the resources involved. A mentor of mine always says "You can have it, but if you break it then you get to keep both pieces". Without value in the broken pieces, no one needs to clean up their own messes anymore, so there's no need to move carefully or fail gracefully. If you trash your dev env, or even your workstation, it's trivial to roll back or redeploy and get back to work. Management is in on it too. Rather than hire more careful devs, it's easier to just move the explosions farther away from prod, and limit the blast radius. CI/CD

[blurbleblurble]

A lot of that stuff isn't gonna last 30 years.

[rbanffy]

That's what we thought 30 years ago and, yet, here we are.

[geggam]

I question your use of the word fun

[ykevinator]

This is totally right.