Learning from History - or not

Author and consultant  Gerald M. Weinberg has been actively involved with the business of computing for over half a century.  He is a renowned and revered figure who has written some of the most influentual books in the industry.

In his Secrets of Consulting blog he recently wrote about the lack of attention to history, and how the hype cycle surrounding innovations and advances in the way we work seems to repeat without organisations and practitioners learning from the lessons from previous cycles.

He was reformatting his book "Rethinking Systems Analysis and Design" for e-book format and decided to update the section (written 20 years ago) titled "Beyond Structured Programming".  He found that merely by replacing the phrase "structured programming" with "agile" the content and intent of the piece could be brought forward to address today's "agile programmin revolution".

He says:

Although this essay was written a generation ago (now two generation), and the agile programming "revolution" is now an exhausted fad (for most programmers), most of what this essay says still applies—though to the next rethinking fad, and the next, and the next. I believe it will still apply long after I'm no longer writing new editions. Why? Because our industry seems to require a new fad every decade to keep itself from being bored. So, just apply the lessons to whatever fad happens to be dominating the computer press at the time you're reading this.

He goes on to discuss how many organisations adopt new practice by paying lip-service and trying to either blindly follow a set of rules, or adopt the easy practices without applying the disciplines that effective change requires.

He says that when agile adoptions are examined in detail:

a. Five percent can he considered thoroughly agile.
b. Twenty percent can be considered to follow agile practices sufficiently to represent an improvement over the average code of 1990.
c. Fifty percent will show some evidence of some attempt to follow some "agile rules," but without understanding and with little, if any, success.
d. Twenty-five percent will show no evidence of influence by any ideas about programming (not just agile) from the past twenty years.

He encourages a careful and thoughtful adoption of agile practices, because:

Those installations and individuals who have successfully realized the promised benefits of agile programming tend to be the ones who don't buy the typical hardware or software pitch, but who listen to the pitch and extract what they decide they need for solving their problems. They do their own thinking, which includes using the thoughts of others, if they're applicable. By and large, they were the most successful problem solvers before agile programming, and are now even more successful.

He concludes the section with a call to considered action:

Our profession contains few, if any, easy solutions. Success in problem solving comes to those who don't put much faith in the latest "magic," but who are willing to try ideas out for themselves, even when those ideas are presented in a carnival of public relations blather.
Based on this lesson, I'd like to propose a new "programming religion," a religion based on the following articles of faith: 

• There's no consistent substitute for a thorough understanding of your problem, though sometimes people get lucky.
• There's no solution applicable to every problem, and what may be the best approach in one circumstance may be precisely the worst in another.
• There are many useful approaches applicable to more than one problem, so it pays to become familiar with what has worked before.
• The trick to problem solving is not just "know-how," but "know-when"—which lets you adapt the solution method to the problem, and not vice versa.
• No matter how much you know how or know when, some problems won't yield to present knowledge, and some aspects of the problem nobody currently understands, so humility is always in order.

Remember - this article was originally written twenty years ago about structured programming, the only change he made was to replace the term "structured programming" with "agile" - and the message is as applicable today as it was in 1990.

On a similar vein, Elisabeth Hendrickson posted an article titled "Agile Backlash? Or Career Wakeup Call" in which she discusses (anti-)patterns of agile adoption that seem to be taking hold in the industry:

The first pattern involves people who have been burned by a corrupted flavor of “Agile” foisted on them by clueless managers in dysfunctional organizations. By “clueless,” I mean the kind of manager who thinks the way to find a qualified coach is to find someone with a certification from a 2-day CSM class. Or the kind of manager who thinks that if we do a global search and replace on key phrases in our process docs that we will somehow be transformed into an “Agile” organization. By this I mean: 

phase -> iteration
project manager -> scrum master
requirements -> stories
estimated hours -> points
status meeting -> standup

Sadly, there’s nothing we can do to prevent this bastardization of the word “Agile.” It happens with every buzzword. ISO, CMM, CMMi, RUP, take your pick

The second pattern is one that worries her more:

But there’s a second pattern of responses that I find both disturbing and fascinating. The responses in this category do not appear to be motivated by a misunderstanding of Agile, but rather are attacks on Agile practices: standups, pairing, collaborative teams, open team rooms, and the like.
I suspect that some of these folks are introverts working with a whole passel of extroverts who took to the social nature of Agile like ducks to water. Introverts need time and space to process stuff internally. If they don’t get enough time to themselves during the workday, they burn out. If this sounds like you, I hope that instead of seeing Agile practices as evil you can work with your team to achieve a workable balance of collaboration time and alone time.

She goes on to discuss how many of the previously tolerated social behaviours are no longer acceptable in agile teams and how social and emational maturity are important aspects for teams today.

The truth is that creating even a modestly complex software system is of necessity a social activity, a team sport. It is not enough to be brilliant. It never was. Effective team members have social skills. They listen, collaborate, share, and contribute.

InfoQ examined the Agile hype cycle in a recent article - Is Agile in the Trough of Disillusionment?

So - has the computing industry learnt anything from the patterns of history, or are we doomed to repeat the hype cycle with every new idea?