Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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? )

share|improve this question
6  
Well I hope that it doesn't have anything to do with the half-life of the number of releases of Half-Life sequels. :) –  Adam Arold Mar 20 '11 at 16:56
    
Updated question to encompass long-lived programming concepts (e.g. loops etc) –  Gary Rowe Mar 20 '11 at 17:03
    
How does this account for the variable component in our knowledge ,that keeps increasing every day and as and when we encounter new things? –  Aditya P Mar 21 '11 at 6:31
    
@AdityaGameProgrammer Overlapping curves. You learn something new and it slowly decays to irrelevance, but you're always learning something new so you get overlapping decay curves. –  Gary Rowe Mar 21 '11 at 9:12
add comment

marked as duplicate by Dan Pichelman, Karl Bielefeldt, gnat, MichaelT, mattnz Aug 24 '13 at 7:04

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

11 Answers

up vote 23 down vote accepted

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.

share|improve this answer
2  
+1 for algorithm observation - I wonder if mathematics has a half-life? –  Gary Rowe Mar 20 '11 at 17:05
3  
TAOCP was first published in 1968 and is still a great reference. Languages come and go but algorithms have a longer shelf life. +1 –  dbasnett Mar 20 '11 at 17:14
2  
@Gary, mathematics certainly have a half-life. I was very good at calculus, once upon a time. Haven't used it in 18 years and I really couldn't remember a thing about it, though I imagine if I picked it up, I could learn it quicker than someone with no background. The important question for me is why couldn't I choose to retain that knowledge in favour of those Duran Duran lyrics that still haunt me? –  pdr Mar 20 '11 at 19:03
1  
@pdr: If you get them to make a song where the lyrics are based on mathematical formulas, you'd be set. ^^ –  gablin Mar 20 '11 at 21:01
2  
@pdr: that's half-life of your memory, calculus stays the same. –  Den Aug 23 '13 at 11:33
show 1 more comment

As you move further from the "center" of knowledge you get shorter and shorter half lives. At the very center you have the analysis of algorithms and data structures that may be superseded someday but probably not within my lifetime, then you have programming paradigms something that hasn't changed in my lifetime but may, next comes languages now you are at least in the realm of decades, and at the edges you have techniques and libraries that change every few years.

share|improve this answer
add comment

That statement is true in the context of cutting edge code and technologies, however, in the context of overall development, which is including legacy code, it is not true from my experience. As a consultant, I'm constantly switching between technologies as I move between different clients.

For example, my last position involved Spring 3.1 using Annotations and Web Services with CXF, but prior to that I recently had to do work with some very old legacy java code (15 year old+ codebase) that had recently upgraded to Java 6. Another client I worked for is still using EJB 2.0 and isn't changing anytime soon.

My point is clients have invested heavily into certain technologies and they aren't going to change overnight. Those technologies and codebases are generally stable, so the client doesn't want to jeopardize that investment by constantly changing their core technologies. Therefore, older skillsets will always be in some demand beyond the 18 months guideline.

Keep in mind one of the cardinal rules of business, things always change! Whether it's fast or slow, every industry always experiences change. One notable example in our industry was change that Y2K brought for COBOL developers. I would have never thought their pay rates would rise, but they did around Y2K and then adjusted themselves afterwards. I had a relative that was doing COBOL at that time and he said he knew it wouldn't last, but he was getting good pay at that time.

So my point is learning programming knowledge is not static. It's a dynamic thing that can change. I still get contacted for Visual Basic work, but I haven't done that work since 2001 when I switched over to Java development.

Again, the question is true, but not in the universal sense that you imply in your question. It is not a universal maxim for programming, like "Bug free code is more important than clean code" or "Keep things as simple as possible but not simpler." or "Don't re-invent the wheel" and such like.

share|improve this answer
add comment

I think a good programmer will be a good programmer, regardless of the language or tools you give them. The basic ability to read and understand a requirement, write code that does not fail, is maintainable, and produce the requested output, is and has always been core of a programmers job.

Saying that, it does not mean your marketability in the work force does not fade with time. Walking out of college with a degree and thinking you will be employable with just that knowledge is foolish. The field suffers from fads, those buzzwords bosses see in CEO magazine and assume that has to be the silver bullet to their high IT budgets.

To be marketable, programmers have to be adaptable, and open minded. You never know how things will turn out. I have been batch program writers in COBOL programmers can translate those skills into successful Hadoop PIG Latin.

I suspect, those who are reading these forums are already aware that a programmer has to keep learning. Those that don't think so, probably don't spend time reading questions like this.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
1  
What happened with hypertext in 1910? Was there a person or a paper or something I could Google? –  Panzercrisis Dec 11 '13 at 16:16
add comment

"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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
1  
+1 for faddish idioms. Talk to a hardened Lisper and OOP is a fad. –  Gary Rowe Mar 20 '11 at 17:15
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.