Comment by barrkel | Hacker News Reader

Comment by barrkel | Hacker News Reader

Parent Full thread

Software development has eternal amnesia. Deep understanding of the pros and cons of different ways of structuring things are being continuously re-learnt with each passing fad, and each rewrite of a legacy system by a bright new crop of young things who learned most of what they know with a decade or so of direct experience.

Different concerns have different emphases in each fad, but the systems built have structural isomorphisms with what came before - they could hardly avoid it, being built to solve the same problems - and the older experience is lost, because people focus on the surface, rather than the larger shape. Older experience is dismissed because it was in an outdated language, despite it containing lessons that will continue to be applicable.

Everyone is myopic. It's like politics; the appearance of things is what matters. It's like fashion; it's the intersection of the ideas associated with the surface structure of your output that define its perception. No wonder older developers tend to leave this industry.

> You want to make your way in the CS field? Simple. Calculate rough time of amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the dusty archives, dig out something fun, and go for it. It's worked for many people, and it can work for you. - Ron Minnich

But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. And yet somehow it doesn't work like that, outdated things are in fact outdated and you can only take away very little from them. Things that were designed with trade offs for very expensive slow synchronous machines during the times when programmers were not bound to languages, because everyone had to develop everything from scratch, don't really make much sense today. Direct experience of the last decade is a lot more relevant with a lot more lessons to learn that were never even on the radar in the past.

There's a variety of reasons. It's often because our languages are too low-level and the architecture too opaque, such that you need to study a codebase for a long time to understand what works well and what doesn't work so well. The hill you need to climb to reach an epiphany is sufficiently steep that people much rather build their own hill, and learn their own lessons.

The trade-offs come around and around, the lessons are not as inapplicable as you think. We used to struggle to run programs on small machines; those struggles came back again with mobile, and come back again in a slightly different guise in clusters (where the program is too big to fit on any one machine).

They recur on different scales, too. Just the other day I was looking at dependency injection. Dependency injection solves the problem of coordinating dynamic program composition; the reason the program needs to be composed is because it was decomposed for testing. But this is just another iteration of the same pattern come around again. It's been done before in a large variety of ways; sometimes through ambient configuration (global variables), sometimes with patched jump tables (dynamic linking), sometimes statically (module instantiation). The emphasis is different - testing - but the solution is not structurally novel in the least.

> But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so.

Hah! Reasons for not learning from history:

* history is hidden behind NDAs, bad licences and patents

* history is hard to access due to its environment (printed on out-of-print books, stored on tapes, HDD and other forms of storage in someone's basement)

* history is written in a programming language nobody knows anymore

* history is written in an incompatible programming language, one for which there are no stable bindings to your favorite language (or for which there aren't any bindings, period)... just think how many times the String class or data type has been written and rewritten just in something like C, let alone the copies in Java, PHP, Ruby, Javascript, Go, Rust, etc., etc.

There's a ton of (somewhat) valid reasons history is forgotten and most of them aren't "history was bad, let's just forget it".

True, but many of those hurdles are easy to overcome when one is curious about history of computing, specially since many libraries have been scanning old books and papers.

For example, I have collected the majority of Xerox and DEC research papers that I could get hold of.

> Direct experience of the last decade is a lot more relevant with a lot more lessons to learn that were never even on the radar in the past.

Do you make that statement with the experience to back it up? Or do you make it because "if it were useful someone would have done it"? What if everyone is thinking the same thing as you are?

Beyond what other people have said, we are also a relatively young industry. There aren't that many people with 30, 40 years experience in the field. When I got my CS degree, 13 years ago now, there was no such thing as a "software engineering" degree, and CS was mostly focused on CS rather than the sort of thing you're talking about.

I also wonder how much collective knowledge we throw away with pushing developers into management. Or the outsourcing in the late 90's and early 00's. Or ageism. We are purposefully driving people with knowledge out of the industry.

> When I got my CS degree, 13 years ago now, there was no such thing as a "software engineering" degree

That is country specific.

I took my degree around 20 ago and is it called "Degree in Software Engineering", certified by our Engineering Society.

http://www.fct.unl.pt/ensino/curso/mestrado-integrado-em-eng...

Created in 1977.

100% on spot, the fashion driven software as Alan Kay puts it.

Reply on news.ycombinator.com