TITLE: Isaac Newton, Failed Agile Software Developer
AUTHOR: Eugene Wallingford
DATE: October 14, 2004 8:15 AM
DESC: Another professional article criticizes agile methods in a strange, unsatisfying way.
Every once in a while I run across an article in a journal or trade
magazine that reflects some misunderstandings about agile methods.
Last July, I
blogged about an article
from a CS education magazine which asserted that using agile methods
was unprofessional. (Presumably, then, so is teaching them as a viable
alternative to traditional methods.)
pointed the members of the XP discussion list to an article in the
October issue of IEEE Computer called "Do Agile Methods
Marginalize Problem Solvers?", by Victor Skowronski. (The article is
to IEEE-CS members.) As Steve said, this column "sounds like it was
written by someone who has read about agile methods but not used them."
Skowronski's argument seems to be this:
This, of course, means that agile methodologies are unsuitable for
many (most?) software projects.
The article uses two of history's great thinkers as examples: Isaac
Newton and St. Thomas Aquinas. Apparently, Newton wasn't much of a
team player, feuding with rivals, guarding his advances until
publication, and preferring to work in isolation. Aquinas, though,
was just quiet, a man living the life of the mind irrespective of
his social circumstances.
Would I really want a Newton on my team? Most software developers
aren't writing software that will change the intellectual foundation
of a discipline or even a company. They don't need to create new
ideas of the depth and complexity of Newton's advances.
Most software developers also don't get jobs for being pains in the
Would I want Aquinas on my team? Maybe. I can imagine having
an excellent programmer be a valuable contributor to my team even
though he is unable to pair effectively. I've never worked in
such an environment, as my agile background is limited to teams
that chose to use agile methods on their own, but I can imagine
it. Maybe over time the loner becomes an effective pair; maybe
instead the team adapts to the loner. It could work.
Like so many articles of this sort, this one projects a lot of
details into the description of agile methods that aren't really
there. Perhaps this projection follows from never having tried
agile methods, or maybe from an ideological bias. In any case,
this article makes assumptions that demean agile proponents'
professionalism and ethics.
Forcing programmers into a communal workspace with no opportunity
for either personal or professional privacy in the work place?
Discouraging the writing of all documentation? Building software
without adequate knowledge of one's task, tools, and domain?
Please. Those aren't agile practices. They are just bad ones.
A big part of the article discusses how the phases of problem
solving fit with an agile approach, but it is largely beside the
point. When an agile team needs to solve a thorny problem, agile
developers can read books and seek other sources of information.
They can take time away from the active production of code, if
that's what's needed. The team can make reasonable decisions
about how to advance its work.
I did have some good thoughts as I read this piece, reminders
to be agile:
- Excellent problem solvers often have personalities ill-suited
for teamwork and, further, must often work in ways that do not
match well with teamwork.
- Agile methodologies favor people with lesser technical skills
and strong "people skills" over excellent problem solvers and
others with technical skills whose people skills are subpar.
- Thus, agile methodologies are unsuitable for environments that
require excellent problem solving skills and thus must attract
people who have them.
Throughout this article, the author seems to imply that you can't
find good problem solvers who are capable of working on an agile
project. Hogwash. Not every person who excels at problem solving
behaves as badly as Newton. I know a lot of smart people with
great technical and problem-solving skills who use agile methods
and like them. They wouldn't choose to develop software any other
way. Furthermore, not all software teams need a problem
solver as singular as Newton. Writing software is hard, but it
is rarely as hard as inventing the calculus.
One other claim caught my eye. This article defines the "best
programmer" as the one with the most advanced problem solving
skills. This is almost certainly the wrong answer. The best
programmers are those people able to deliver high value to their
customers for suitable cost. Problem solving is certainly an
important component in being able to do that. It is essential
that software developers be able to think deeply and to find
solutions to thorny problems. But problem solving is not the
only requirement for a good programmer; indeed, often
it's not even the most important one.
I know that this article is presented as an opinion piece, in a
column that the editors of IEEE Computer hope will stir
up foment. In that regard, I suppose, this piece succeeds. But
still I wonder about the disinformation and misunderstanding of
agile methods that cause people to write such stuff. I hope
that Mr. Skowronski does better research before diving into one
of those really hard problems that he needs to solve.
- Adapt to your personnel. Certainly. Agile processes
aren't just about software; they also encourage us to be
agile in how they work with people.
That said, you should take care in assembling any software
team, and an agile team is no exception. You may choose not
to have a Newton or Aquinas on your team, if they don't fit.
You might choose not to have lots of different kinds of people
on my team.
- Don't overlook developers who can contribute value but don't
fit your stereotypes. This is a variant of the previous
point. The article reminds us that a good problem solver who
lacks people skills may seem less competent than a person who
fits the agile mold. We certainly don't want to overlook
potential contributors. We need to watch for opportunities
to bring potential contributors onto the team and help them
to contribute. They might even grow in the process, too.
- Use methods appropriate to your project and environment.
Well, certainly. Agile is as agile does. We need to mold
our approach to the task at hand. But that doesn't mean
throwing out things that we value as essential, like