Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
191.8 167.2 186.2 183.6 184.0 183.2 184.6

Sat, 06 Aug 2005

Two solutions

(After a couple of days trying, off and on, to make a narrative of threats to Agile work, I give up. I also give up on the cybernetics tie-in. It gave me ideas, but I can't use it to express them. So it comes down to three solutions and their justifications. And every time I write about the last of them, I see it in a different way, so I'm going to cut my losses and put up the first two until I can say something coherent about the third.)

What we need is...

... an undergraduate-level textbook and course

I'm thinking here of an Agile alternative to texts like Sommerville and Pressman: books that intend to be the only text for a survey/project course, books that go through edition after edition, books that are referred to by author name rather than title.

I'm inclined to agree, with Kuhn, that textbooks both mark and help cause the transition of a particular style ("paradigm") from something revolutionary to something normal. As Agile goes mainstream, a textbook will be a significant marker.

A textbook will, I'm assuming, come with instructor support: teaching guides, sample problems and solutions, advice on fitting Agile teamwork into student schedules and the physical infrastructure (dorm rooms, and carrels filled with people who don't want to hear chatter). I get the impression that Agile courses are more work for instructors than conventional high-ceremony courses, so such materials will be needed to get overworked instructors to switch to something new.

The existence of such courses is important in two ways. First, it will route more students into Agile. They'll have a "routinized" way of discovering it, instead of relying on chance contacts with inspiring people or texts. Second, it will slot Agile into the routine of hiring. Yes, that routine is impersonal and lossy in many ways. But companies hiring, say, undergraduate physics majors have an advantage. They can look at a resume and be pretty sure that the candidate knows a particular set of facts and has been drilled in a set of techniques. So scarce interview time can build on that base. We know nothing of the sort: does the person know TDD? Has she ever refactored? Does she understand the test-code-refactor cycle? Has she ever been in a standup meeting? Does she know why they work? (This ties in with Josh Kerievsky's claim at Agile2005 that the amount of time coaches spend teaching basics is retarding the spread of Agile within companies.)

I realize I'm talking about something intensely political: even when the author describes a superset of Agile ideas and techniques, rather than a common core, such a book serves to define a field. When ideas get left out, people get mad. I am convinced my schtick about tests as examples will get left out, and that's wrong, wrong, wrong. But I'll have to live with it.

Notes:

  1. At Agile2005 a couple of instructors told me that they happily assign multiple books: Refactoring, a test-driven-design book, etc. I'd prefer that - if only because such books stand a chance of being opened after the final exam - so I could be wrong about some of the need for a survey textbook. But there's still the need for instructor support materials.

  2. I'm a fan of alternative education, like Dave West's Bachelor of Arts in Software Development Technology or RoleModel's apprenticeships or the Planetary Collegium. But we'd be foolish to bet against society's dominant form of job training, despite its well-known inadequacies.

  3. Bill Wake's Refactoring Workbook seems to me a great instructor guide or supplementary text. I wonder how much it's used?

... to take over a computer science department

If you say "Agile in academia" I think of people: Rick Mugridge, James Noble, Grigori Melnik, Robert Biddle, etc. The only university name that comes to mind is North Carolina State, but I just checked the home pages of all the faculty there, and it appears that Laurie Williams is the only one interested enough in Agile to mention it.

Scattered individuals have extra trouble making progress. Compare to my wife's department. There are several professors whose interests are close enough to hers that they routinely publish together. Because they're all in the same place, they can bounce ideas off each other at random moments. And I'm especially interested in how they trade favors with each other and thus exploit comparative advantage to the benefit of all. Conferences are great because they're concentrated events that raise people's emotional energy and increase cultural capital, but they're not enough.

The lack of departments with a concentration on Agile hurts development of the field in other ways. In 1976, I wanted to be an astronomer. Going to Caltech was an obvious choice. Eight years later, I was peripherally involved in the big AI boom (as a Lisp implementer). Had I wanted to get a graduate degree in AI, there would have been obvious places to go: MIT, CMU, Stanford. Going to a department with a specialty in AI is less risky than going to work with a person who specializes in AI: it's easier to recover from bad luck - personality mismatches, your mentor leaving for another university. Because of that, some potentially productive people will go a different field. We want them all.

Accomplishing this takeover is an exercise left to the reader.

## Posted at 12:56 in category /conferences [permalink] [top]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.

 

Syndication

 

Agile Testing Directions
Introduction
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects
Postscript

Permalink to this list

 

Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list

 

Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI

 

Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."

 

Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich

 

Where to Find Me


Software Practice Advancement

 

Archives
All of 2006
All of 2005
All of 2004
All of 2003

 

Join!

Agile Alliance Logo