Does programming knowledge have a half-life?

Question

In answering this question, I asserted that programming knowledge has a half-life of about 18 months.

In physics, we have radioactive decay which is the process by which a radioactive element transforms into something less energetic. The half-life is the measure of how long it takes for this process to result in only half of the material to remain.

A parallel concept might be that over time our programming knowledge ceases to be the current idiom and eventually becomes irrelevant. Noting that a half-life is asymptotic (so some knowledge will always be relevant), what are your thoughts on this?

Is 18 months a good estimate? Is it even the case? Does it apply to design patterns, but over a longer period? What are the inherent advantages/disadvantages of this half-life?

Update

Just found this question which covers the material fairly well: "Half of everything you know will be obsolete in 18-24 months" = ( True, or False? )

Answer 1

Only knowledge of specific technologies get old, and not even that gets old so quick. C has been around since the early 70's, it is still highly relevant in today's world, and not that much has changed in it. Sure, there have been some changes, but the basis of that knowledge is still there.

All programming languages, libraries and so on get updates, but your old knowledge won't be obsolete very quickly as the changes probably won't be very drastic, at least from your point of view.

Then again, we have timeless knowledge about algorithms, artificial intelligence and so on; new discoveries come, but your base knowledge in these will be true a thousand years (well, maybe not that long, but it isn't up for you to worry about) from now, just like in most other fields.

Finally, over time, you learn how to think about problems in specific ways. That won't become obsolete.

Answer 2

For as long as programming exists, it has been about exactly two things: abstraction and re-use. I don't see that changing anytime soon.

In fact, almost nothing new has been invented in programming in almost 30 years. Pretty much everything you learned in 1980 is still relevant today. Probably even more so, since back then, programmers actually understood what programming is about: not variables. Not loops. (In fact, the concept of "loop" implies mutable state, which is in almost every case an anti-pattern.) Not switch statements. Abstraction and re-use.

The most popular thing today is writing MVC web applications in Java/C#, a class-based statically typed object-oriented language with automatic memory management and first-order generics. That sounds exactly like Eiffel, which has been around since 1985, OO has been around since 1953, 1960, 1967, 1971 or 1976, depending on your definition of OO, garbage collection since 1958, generics since 1975, MVC since 1977, the WWW since 1993 (but the general concept of hypertext since 1910), IDEs since the 1970s.

Heck, even the architecture of our computers, though in desperate need of an overhaul for more than a decade, is still based on the original IBM PC from 1981 and the CPU's ISA has really only changed twice since 1978, in 1985 and 2002.

Answer 3

There is certain knowledge that won't become redundant - the basics such as loops, switch statements, program flow etc. However, there will always be new ways of implementing these things. These will be built on existing knowledge and systems so what you know now will still be required to understand the new.

What is important is that you should always be open to new ideas, but don't blindly accept them. Doing something the "old fashioned" way may still be the better way as it leads to code that's easier to maintain.

Answer 4

I disagree.

There might be specific bits of information that people forget (e.g. someone used to work a lot in java and then moved to .NET, and they might forget some of the API). But the "programmer knowledge" is far more than that. What I consider programmer knowledge is the processes and workflows of developing software. The way you make software. The ability to design and implement an algorithm. To some degree, business analysis. The design principles.

I don't think that this stuff fades that easily.

CW, feel free to add

Answer 5

I disagree with the premise that programming knowledge has a half-life. I would agree with a statement that fads/fashions have a half-life and that many of our idioms are based on fads.

Answer 6

So experience means nothing?

Topics like design patterns and algorithms help programmers do their tasks better long after the implementation is forgotten. Knowledge is not the ability to regurgitate fact; it's getting something something of value by taking in new information.

Answer 7

"half life" means that the obsolescence of knowledge is exponential. It's obvious that some of the things that any programmer learns become obsolete quickly, but why would you conjecture without some evidence that the rate is exponential? Why not linear?

In my experience, learning what I know now felt more linear than exponential. I'm still learning, but I'm sure I won't know twice as much 18 months from now as I do now. If I didn't touch a keyboard or pick up a programing book for 18 months starting now, I'd fully expect much more than half of what I know to still be useful when I got back to it. Sure, I'd be rusty, and I'm sure that even my typing skills would have deteriorated a bit, but I'd hope to be productive again within a week.

Answer 8

The people aspects and the various ways of writing clean, maintainable code never gets old no matter what framework or language you are working in.