Home > technical > Battling The Confirmation Bias

Battling The Confirmation Bias


On my first pass through Bertrand Meyer’s “Agile!” book, I interpreted its contents as a well-reasoned diatribe against agilism (yes, “agile” has become so big that it warrants being called an “ism” now). Because I was eager to do so, I ignored virtually all the positive points Mr. Meyer made and fully embraced his negative points. My initial reading was a classic case of the “confirmation bias“; where one absorbs all the evidence aligning with one’s existing beliefs and jettisons any evidence to the contrary. I knew that the confirmation bias would kick in before I started reading the book – and I looked forward to scratching that ego-inflating itch.

On my second pass through the book, I purposely skimmed over the negatives and concentrated on the positives. Here is Mr. Meyer’s list of positive ideas and practices that “agile” has either contributed to, or (mostly) re-prioritized for, the software development industry:

  • The central role of production code over all else
  • Tests and regression test suites as first class citizens
  • Short, time-boxed iterations
  • Daily standup meetings
  • The importance of accommodating change
  • Continuous integration
  • Velocity tracking & task boards

I should probably end this post here and thank the agile movement for refocusing the software development industry on what’s really important… but I won’t 🙂

The best and edgiest writing in the book, which crisply separates it from its toned down (but still very good) peer, Boehm and Turner’s “Balancing Agility And Discipline“, is the way Mr. Meyer gives the agilencia a dose of its own medicine. Much like some of the brightest agile luminaries (e.g. Sutherland, Cohn, Beck, Jeffries, Larman, Cockburn, Poppendieck, Derby, Denning (sic)) relish villainizing any and all traditional technical and management practices in use before the rise of agilism, Mr. Meyer convincingly points out the considerable downsides of some of agile’s most cherished ideas:

  • User stories as the sole means of capturing requirements (too fine grained; miss the forest for the trees)
  • Pair programming and open offices (ignores individual preferences, needs, personalities)
  • Rejection of all upfront requirements and design activities (for complex systems, can lead to brittle, inextensible, dead-end products)
  • Feature-based development and ignorance of (inter-feature) dependencies (see previous bullet)
  • Test Driven Development (myopic, sequential test-by-test focus can lead to painting oneself into a corner).
  • Coach as a separate role (A ploy to accommodate the burgeoning agile consulting industry. Need more doer roles, not talkers.)
  • Embedded customer (There is no one, single, customer voice on non-trivial projects. It’s impractical and naive to think there is one.)
  • Deprecation of documents (no structured repository of shared understanding to go to seek clarification on system level requirements/architecture/design issues; high maintenance costs for long-lived systems; costly on-boarding of new developers)

I’ve always maintained that there is much to like about the various agile approaches, but the way the agile big-wigs have been morphing the movement into a binary “do-this/don’t-do-that” religious dogma, and trashing anything not considered “agile“, is a huge turnoff to me. How about you?

Obscured By Hype

  1. January 21, 2015 at 8:02 am

    Nice post. The positive points listed are very reasonable and sensible (almost common sense?). I made an honest effort at TDD, it made me uncomfortable and I thought it was stupid. I much prefer to start with some design and prototyping.

    • January 21, 2015 at 10:19 am

      Shhhhh! You’re not supposed to say stuff like that in public. 🙂

      I also tried TDD using the book “Unit Test Frameworks” for guidance. Didn’t like it either. It works for a lot of people, but I’m not one of them.

  2. January 21, 2015 at 2:46 pm

    Nice post, 100% agreement about scaling issues, missing capabilities based planning, and other “naive” approaches to enterprise and mission critical software from agileist

  3. January 22, 2015 at 6:51 pm

    Enjoyable writeup. “Balancing Agility and Discipline” remains one of my standout resources for matching methodology against the development task at hand. Sounds like I’d enjoy “Agile!” too.

    • January 23, 2015 at 3:51 am

      Thank you.

      Agile! is a breath of fresh air. Meyer is a great writer. If you liked Bohm & Turner, you’ll love Agile!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: