Being the same vintage as Jim, much of this brought back memories.
There really wasn't any such thing as a tech stack - our company would produce software for various Unixen and, especially, Vax, and the language was alway C, with some Pascal on the Vax side (as, I was told, the Vax Pascal compiler produced far more optimal code than the C compiler).
Being a software engineer was like being a furniture-maker. You had to master a small number of tools - the saw, the chisel - and then craftsmanship consisted of discovering an affinity with these tools and a love of getting ever more skilled at using them. This path wasn't for everyone, which was fine - plenty of management and other non-tech roles for those folks - but if you grooved with your tools it was a real joy to be able to move from chair- to table- to cabinet-making and carry and refine your skills as you went.
This idyll could not last, however. Before too long it became uneconomical to make furniture this way, so for your chair making project you instead had to learn how to run a chair-making machine. When you moved onto a tables project, the machines there were infuriatingly dissimilar to the chair-making ones you'd just mastered. Worse still, moving back to chair-making after a year or two, you discover that the old machines you knew are now obsolete and you have to re-learn how to run their replacements. This stops being fun, or interesting, after a while, and yet sadly it's all that most younger software engineers know.
Occasionally, there is the need to make some shim or gizmo that the machines don't cover, so out come the trusty saw and chisel of yore - much to the amazement of the young'uns, who are astonished that an old-timer can still wield these antiques so effectively.
> Worse still, moving back to chair-making after a year or two, you discover that the old machines you knew are now obsolete and you have to re-learn how to run their replacements.
Love your analogy, it's all spot-on.
On the above, I'll add that the new chair-making machine is hardly ever better than the one from 2 years ago that you saw, it's simply all completely different for the sake of being disruptive to you its user. Most of the time it's actually worse, with fewer features and more restricted customization.
As a youngster who has had to pick up a saw and chisel to repair an old chair, I think you're looking back with rose tinted glasses a bit. I've never been astonished by legacy code, as much as bemused for the lack of object orientation, data normalization, etc. The technology changes of course, but there are advancements made in craftsmanship/techniques.
There's some 'cleverness' lost probably, in the new ways vs the old. I've seen some pretty novel approaches to what should be simple tasks in legacy code. And I do recognize that for what it is. But as impressive as that cleverness can be, I think it's one of the reasons as to why a lot of legacy code persists and nobody wants to touch it. Among many other reasons.
Huge disagree on this. Old code tend to be much more terrible because the tools were terrible. They gave little incentive and absolutely no help to write even passable code. We end up with a mess of poorly documented, sparingly commented spaghetti code that sometimes work, often by accident.
Nowadays, we have linters to point out common classes of mistakes, programming languages with actual type systems to enforce invariants, integrated testing tools, etc...
Note that, yes, we do still have new, terrible codebases. But at least the tooling nowadays raised the bar to have a minimum floor of quality that, while very low, is still oh so much higher than it used to be.
> Huge disagree on this. Old code tend to be much more terrible because the tools were terrible.
I've looked at 1990s code in the Windows NT kernel. It was wonderful.
Oldest source file I went through was from 1993. Perfectly readable and understandable.
One of the best modern code bases I ever worked in didn't even have a linter setup. The principle dev reviewed every single commit and enforced a consistency across the code base that was better than what any tools ever could have done.
> The principle dev reviewed every single commit and enforced a consistency across the code base that was better than what any tools ever could have done.
How was it so much better that it justified that level of busywork on the part of the senior member of the team (and busywork for everyone else, to fix the style nits they enforced in review)? I would have guessed that taking a few hours to install and configure a formatting linter to free up the principal dev's time to focus on other things would have been hugely high leverage.
It ensured not only consistency of style, but also consistency of ideas. Every file was structured similarly, impedance mismatches were minimized, work across the entire code base was organized and unified. Junior engineers got a chance to talk to the principle developer about every commit they made, and accordingly their abilities as software engineers skyrocketed.
Developers quickly set their IDEs to follow the team's coding guidelines, style wasn't really a problem.
We had "coding standards," and if you didn't code it to the right format, you'd get fussed at. I didn't start professionally until the mid 90s, so I'm a little younger than the OP. I've been coding since the mid 80s though as a youngster.
Putting BEGIN..END around a one line block was always a contention since it wasn't required. Less code vs arguably more readable code (Pascal)
> The code quality is determined by the author, just like today.
This is nonsense. The worst authors can still produce bad code with the best tools and the best authors can still produce good code with the worst tools, but most authors are somewhere in the middle, and tooling makes a huge difference to the average.
> As a youngster ... as much as bemused for the lack of object orientation.
And as an oldster you be happy again to see the lack of object orientation and not the 5 level misabstracted inheritance hierarchy someone didn't do for purpose but just because university taught the modern way to automatically end up with sane structured code... and sure sure every tool can be used well or misused and never overgeneralize 8-)
I may be wrong but youngsters as oldsters have both their own rose tinted glasses.
I think you might be missing parent comment's point. The way I read it they aren't saying that old code is better, just that you used built everything up from scratch generally (or to a much greater extent than nowadays) instead of using whatever framework is in fashion this week
You also have to understand one thing (source: me, a sw developer since late 80s in Europe) - there was no internet, and most of the people working in the field had no CS degree.
This meant that neat new tricks (and stupid old mistakes) were done and (re)discovered all over the place, ALL THE TIME.
You might have decided that data normalization was a good idea, or you might have maybe got the idea by one of your mentors... but you could not know that precisely the same thing was being done/taught on the other side of the street, or even 2 floors below your office.
Data normalisation was huge in the past because of storage concerns. But it makes less sense now. There's still concerns of inconsistent data and duplication but often it's more performant to not do it to the extreme extent we learned to in the 90s with all the normal forms. It's still a good concept but no longer a strict rule.
The inconsistency can be covered with stored procedures and prepared statements which are also a great way to improve security (SQL injection)
So IMO excessive normalisation is no longer the be all and end all in this day and age. Just the way an RDBMS is always the way to go. Sometimes object storage is better.
But anyway I'm surprised you saw less normalisation in old code. Personally I saw much more then than now.
When I told him about SQL databases. Relational stuff, normalization. Awesome.
He told me that was all fine and dandy but just too slow, this new fangled SQL database stuff. He used databases where you simply accessed rows by key. If you needed to access something by a different key you just made a different table where the same data was arranged by that key instead. Super performant.
Of course my dad also programmed in languages like 370 assembler.
Funny how the young folks today talk about NoSQL databases indeed.
SQL databases were a dumb misstep, it's always baffled me how they ever caught on. In 10 or 20 years we'll look back on them the same way we look on C++/Java-style OO today.
It's not really such a dumb idea actually. It just depends on what you favour. There are plenty of nice things about SQL databases. I suppose it's the regular back and forth between one extreme and another. Both driven by "we need something new to work on" and changing technology landscape.
Relational databases really weren't all that practical back in the day with the hardware that was available. Putting thought into defining how you are going to query your data was available though. Relational algebra wasn't a thing from the start either.
If someone comes along and tells you that you don't have to know all this up-front and you can come up with a query you want to ask about the data you have, you will be able to, isn't that awesome? Ad-hoc, just like that. No need to carefully transform the data you have, ensure you keep it all up-to-date in multiple places etc. Of course data volumes grow and even the newer hardware you have can soon no longer handle what you got in a timeframe that you like. Indexing will be a thing. Of course even indexes grow way too huge to really perform, but hardware to the rescue, where at least all the indexes you need frequently will fit in RAM. Lots of caching going on too for your regular workloads.
Guess where the story is going? Well of course there's the old analytical vs. transactional load thing, i.e. your "Data Warehouse" is a separate database that is optimized for the pre-defined queries again, actually de-normalizing lots of things, being on different hardware, so as not to disturb warm caches for the transactional load etc. And yes, finally NoSQL again, i.e. back to the roots. Put more thought into how you're going to query this as your globe spanning SaaS load won't fit onto the hardware you have available. Of course this brings problems because we're just so good at predicting what kind of query we want to ask about our data. Databases like MongoDB, Cassandra, AWS DocumentDB etc. grow indexes supporting querying arbitrarily ... There's a hole in my bucket dear Liza, dear Liza ... :)
[I'm sure this nice story line is not globally completely correct/adhering to exact timelines but illustrates the point]
A different index, surely, not a different table? This sounds like an ISAM database to me, where you'd have to do lookups manually one by one, picking the right index for each yourself.
To be honest, I don't really know much about what he told me any more and I can't go back and ask him any longer. It's possible but I can't tell you yes or no for sure. It just evoked the memory of that conversation. Same with the Pick and MUMPS the other reply mentions. Doesn't ring a bell, seems possible though.
A puzzle: chair-creation was automated because creating every chair is expensive. Copying and shipping a piece of software costs nearly nothing, and still we're shouldering the absurd complexity of industrial production.
There really wasn't any such thing as a tech stack - our company would produce software for various Unixen and, especially, Vax, and the language was alway C, with some Pascal on the Vax side (as, I was told, the Vax Pascal compiler produced far more optimal code than the C compiler).
Being a software engineer was like being a furniture-maker. You had to master a small number of tools - the saw, the chisel - and then craftsmanship consisted of discovering an affinity with these tools and a love of getting ever more skilled at using them. This path wasn't for everyone, which was fine - plenty of management and other non-tech roles for those folks - but if you grooved with your tools it was a real joy to be able to move from chair- to table- to cabinet-making and carry and refine your skills as you went.
This idyll could not last, however. Before too long it became uneconomical to make furniture this way, so for your chair making project you instead had to learn how to run a chair-making machine. When you moved onto a tables project, the machines there were infuriatingly dissimilar to the chair-making ones you'd just mastered. Worse still, moving back to chair-making after a year or two, you discover that the old machines you knew are now obsolete and you have to re-learn how to run their replacements. This stops being fun, or interesting, after a while, and yet sadly it's all that most younger software engineers know.
Occasionally, there is the need to make some shim or gizmo that the machines don't cover, so out come the trusty saw and chisel of yore - much to the amazement of the young'uns, who are astonished that an old-timer can still wield these antiques so effectively.