Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Learning from History - or not

Learning from History - or not

Leia em Português

This item in japanese


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?


Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Yes and no....

    by Amr Elssamadisy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Now I feel old....

    That aside, I found myself nodding my head in agreement about fads. And I also - sadly - found myself nodding my head about the demise of 'agile' in that fewer and fewer people will be gaining benefits from it as it is expanded and the really important things don't get communicated/practiced.

    On the other hand, I don't see anyone practicing structured programming (but maybe I'm not looking hard enough). I can, however, imagine the core of the agile principles, the focus on individuals and interactions, etc.... being applicable 5, 10 and 20 years from now.

    We're working on an article by Steve Peha soon to be published on InfoQ on how he is taking agile principles and adopting them to our educational system here in the US. Can you imagine structured programming being adopted and adapted to anything else?

  • Re: Yes and no....

    by Udayan Banerjee,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What about iterative development - trail and error - is that not a key element of evolution? I think that is the most important part of agile.

    Points to ponder - 20 years from now will we be interacting with each other or will we interact with a system?

  • Re: Yes and no....

    by Jens Meydam,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Amr,

    ... fewer and fewer people will be gaining benefits from it as it is expanded and the really important things don't get communicated/practiced.

    What are the "really important things," in your opinion?


  • Re: Yes and no....

    by Amr Elssamadisy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What are the "really important things," in your opinion?

    Well, to name a few:
    1) Learning is the bottleneck,
    2) Ownership,
    3) Starting with your own improvement before improving others,
    4) An insane focus on getting DONE every iteration,
    5) A focus on real business value, not something abstract,
    5) Changing the environment to require all of the above.

    Now, as I write these out, I know they are not explicitly taught in part of the agile community, and we speak of "culture" but everyone has a different idea what the culture should be. However, I have found that all of these, and a few more attributes, emerge in any team that adopts agile and lean and gets significant results.

  • Re: Yes and no....

    by Jens Meydam,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks, that's a great list!

    To be honest, I find it interesting that you didn't focus on technical aspects (apart perhaps from number 4 - "Done"). Many coaches with an XP background seem to think that the main problem with half-hearted Agile initiatives is the lack of technical competence, and criticize Scrum for having left out the engineering practices.

    You see the real problems elsewhere - learning, ownership, creating real business value - and I strongly agree with you. Technical competence is necessary but far from sufficient.

  • Re: Yes and no....

    by Amr Elssamadisy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks. You are right, technical competence is necessary but not sufficient, and so is Scrum alone. My suspicion is that areas like I mentioned are necessary and sufficient.

    The other things will pull in technical competence. What's your list of the important things?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p