|
The
Art of War, Part 2: The Sheathed Sword Revisited
Working hard is the single most overrated
virtue in the entire software industry. There are times, yes, when
working hard is the only solution to a problem, but in general
working smart is preferable. I’ve heard others brag about
the long hours they put in, when to me, they are only really
bragging about 1) their own failure to work smart, or more likely 2)
their company’s failure to create a proper framework in which
smart, effective work is valued more than less effective, more
lengthy work.
 |
Ignorant
Folk Hero:
John Henry. This steel driver worked so hard to match the
output of a machine, that he died. He should have
bought more machines. |
In my first look at Sun Tzu’s idea of the
sheathed sword, I covered its application to defeating opponents in
competitive games. The idea applies equally well to the process of
completing a software project. Amazing that Sun Tzu’s little book,
The Art of War, from over 2,500 years ago could strike so
cleanly at the heart of modern software development. He wrote:
“To see victory only when it is within the
ken of the common herd is not the acme of excellence. Nor is it the
acme of excellence if you fight and conquer and the whole empire
says, “Well done!” True excellence is to plan secretly, to move
surreptitiously, to foil the enemy’s intentions and balk his
schemes, so that at last the day may be won without shedding
a drop of blood. To lift an autumn hair is no sign of great
strength; to see sun and moon is no sign of sharp sight; to hear the
noise of thunder is no sign of a quick ear.”
Do you see how this relates to software
development? Let’s turn to more modern day writings on software
development, and then revisit Sun Tzu’s point.
Software Development
Software projects (including all video games)
are notoriously over-budget and over-schedule. Why is this? It has
much to do with the highly counterintuitive nature of software
project management, beautifully described by Steve McConnell in his
book Software Project Survival Guide.
When “project manager” types get involved
in a project, they always want to impose a lot of “process.”
They want tracking reports on this, detailed planning on that,
reporting procedures on the other. It’s only “common sense”
that all the time spent on extraneous bookkeeping like that takes
directly away from the productive time that could have been spent
implementing the actual software. Workers do admit that there’s a
small amount of “thrashing,” or unproductive work, that’s
basically unavoidable. So a graph of how much productive work gets
done during the course of a project looks like this:
 |
| The
mistaken
notion that process is pure overhead and that everything
will just work out in the end. |
This is, of course, total fantasy. I would hope
anyone who’s ever been involved in software development would
immediately recognize that. In reality, software development is an
enormously complex undertaking that requires an enormous amount of
coordination, cooperation, and communication. Defects that appear
early in the process (and they DO appear) magnify in scale like a
growing cancer as the project continues. When things can go wrong,
things do go wrong, and they go wrong quite often in software
development. It’s not the case that smartest and most able
developers commit no errors. Even if that were true, errors and
problems are introduced through coordination and communication
problems, and even through outside factors beyond everyone’s
control—not just through flawed code. So the real question is how
does one go about minimizing, detecting, and correcting errors once
one has admitted the truth that the existence of such problems is an
unavoidable fact?
I can’t say it any better than Steve
McConnell did, so I hope he allows my quote:
“When a project has paid too little early
attention to the processes it will use, by the end of a project
developers feel that they are spending all of their time sitting in
meetings and correcting defects and little or no time extending the
software. They know the project is thrashing. When developers see
they are not meeting their deadlines, their survival impulses kick
in and they retreat to “solo development mode,” focusing
exclusively on their personal deadlines. They withdraw from
interactions with managers, customers, testers, technical writers,
and the rest of the development team, and project coordination
unravels.
“Far from a steady level of productive work
suggested [in the diagram above], the medium-size project conducted
without much attention to development processes typically
experiences the pattern shown [in the graphic below.]
 |
| In
reality, the project becomes more complicated, and despite
the emergency processes instituted, thrashing overtakes all. |
“In this pattern, projects experience a
steady increase in thrashing over the course of a project. By the
middle of the project, the team realizes that it is spending a lot
of time thrashing and that some attention to process would be
beneficial. But by then much of the damage has been done. The
project team tries to increase the effectiveness of its process, but
its efforts hold the level of thrashing steady, at best. In some
cases, the late attempt to improve the project’s processes
actually makes the thrashing worse.
“The lucky projects release their software
while they are still eking out a small amount of productive work.
The unlucky projects can’t complete their software before reaching
a point at which 100 percent of their time is spent on process and
thrashing. After spending several weeks or months in this condition,
such a project is typically canceled when management or the customer
realizes that the project is no longer moving forward. If you think
that attention to process is needless overhead, consider that the
overhead of a canceled project is 100 percent.”
Processes like change control, QA, defect
tracking, automated source code control, and so on are the methods
of winning the battles against Murphy’s Law before the full-scale
war is allowed to begin.
 |
| Projects
that attack problems before they become problems win the war
with sheathed sword. Process becomes fine-tuned and
second-nature, while thrashing is reduced. |
The Art of War
And so we return to Sun Tzu’s words. The
generals who win our praise are those who, through great effort, win
large, dramatic battles. The far greater generals who should win our
praise, though, are those who avert war altogether. They defeat the
seeds of war long, long before the masses realize that there was any
danger at all. This is especially true in the case of software
design, since errors that appear early in the process become more
and more costly and difficult to fix as the project progresses.
Imagine a sentence in a design document describing how a particular
piece will be implemented. How easy to change that sentence if it is
in error and avert disaster, yet how hard to re-implement the entire
module that later grows out of that sentence.
An Example
I worked at a company that was, like most
software companies, entirely set up to praise hard work and not at
all set up to praise kind of general Sun Tzu was talking about. In
this company, two teams worked loosely in parallel from the same
starting code base to create two different, vaguely related
products, with roughly the same development cycle.
The actual quality of this software as far as
end user is concerned—the game design—is totally irrelevant to
this discussion. I know I like to talk a lot about game design, but
let’s focus on software design for the moment. The lead programmer
on my team was a careful, pensive, steady man. To him, the beginning
of the project was a time for cleaning up the code base and
reorganizing it to save time later. He was interested in creating a
number of tools and processes designed to uncover code errors early
in the upcoming development cycle.
I called this guy “the anchor.” I felt I
could sleep at night without worrying that the project would float
off into an iceberg in the middle of the night, or something. His
steady work made the final stages of the project pretty much by the
book. The game made it through Sony’s incredibly rigorous approval
process on the first pass.
Meanwhile, the sister project encountered a
number of mysterious bugs towards the end of the project cycle. This
was not surprising since their process was not as rigorous as that
taken by my team’s lead. Tracking down some of those bugs was a
monumental effort. Several of the programmers became company heroes
by staying at work all night, working straight through with no sleep
on countless occasions. Every time their project reached the
“final candidate” stage, some new bug would be discovered,
another monumental effort to fix it would take place, another final
candidate would be created, then yet another bug would be found.
Only through hard work totally unheard of in most industries and
totally counterproductive to the well being of human workers was
that project finally finished. (Let’s just say they didn’t get
Sony’s approval the first time through.)
The management of the company couldn’t say
enough good things about those guys who were working so hard. I mean
they were examples we could all learn from. The CEO gave out awards
to some of those programmers on the other team who had worked far
above the call of duty. “The Anchor” did not receive one.
I am offended by very few things in this world,
but that was one of them. First of all, those programmers who
sacrificed their life and their health to pull of some kind of 11th
hour Herculean win were not working beyond the call of duty. The
company expected that from them. Worse yet, the far greater general,
the general who had defeated armies of bugs before management or
anyone else even knew a war was coming, was not given an award that
day. His contribution—though profoundly greater than the other
team’s, though the true example of how software development should
be conducted—was not visible. When one wins the war before masses
know there was to even be a war, the hero goes unnoticed.
In closing, Sun Tzu in his Art of War
had this to say about the tragic, hero-general:
“…his victories bring him neither
reputation for wisdom, nor credit for courage. For inasmuch as they
are gained over circumstances that have not come to light, the world
at large knows nothing of them, and he therefore wins no reputation
for wisdom; and inasmuch as the hostile state submits before there
has been any bloodshed, he receives no credit for courage.”
Talk back!
Discuss this article in the forums.
|
 |
| "When
the going gets tough, you gotta buckle down and use a little
elbow grease, not write essays on being smart." |
|
| "Monkeys
like me aren't usually appreciated until we're dead." |
|
