“mistakes” though sheer blind luck—
when we just happen to hit on the optimal solution right out of the box.
Imagine walking through a dense
forest for the first time. It would be
almost impossible to get through
the whole forest without taking a
“wrong” turn. The journey must necessarily involve a certain amount of
eliminating incorrect paths. Sometimes the only way to do this is to
actually explore the wrong paths, because we don’t know they are wrong
until we try them. In fact, we could
argue that the highest source of value in software development is only
in exploring new ways to do things.
If we are able to navigate through
the forest without a misstep, it must
be because: we have already been
this way before (in which case why
are we doing it again?); or we have
a map (which means that someone
has been this way before). If we can
get through the forest both without
error and very quickly it must be because someone has built a highway
through the forest. If so, we are going
toward the same destination, and
building the same system, as everyone else. The real value in software
is on the road less traveled, but we
cannot travel this road without some
exploration, and that means diverging from the path.
You normally do it wrong, or at least
it takes you many attempts to do the
job properly. Clearly, you aren’t smart
enough to do it right without my guidance. In fact, without my leadership
you aren’t even smart enough to realize that you are doing it wrong at all.
If this truly is the first time, we cannot
“do it right” because:
˲ We don’t know how to do it right
(because it is the first time).
˲ Wemaynotevenknow what“right”
is (because it is the first time).
˲ Doing it “wrong” may be the only
way to find out what “right” is.
˲ We may actually learn more about
the problem, the solution, or the business, if we do get it “wrong.” An advocate for this approach was Thomas
Alva Edison who was quite famous for
getting it “wrong.”
The Cliché: “Work
smarter, not harder”
This is a fine cliché, since it strongly
implies that the cliché-er is actually
being solicitous of the health and well-being of the cliché-ee. There are so
many sneaky positional inferences in
this cliché that it makes a very effective
one. It has that element of truth that
makes it difficult to argue against, too.
Excessive work may well be a symptom of not having sufficiently thought
through the problem. However, many
organizations think that software is a
product to be produced (rather than a
knowledge medium to be populated),
so the job of a software developer is
to build something (rather than learn
something), so the engineers should
be working rather than thinking.
It’s your fault you have to work so hard,
since you aren’t working smarter, so
you shouldn’t complain about the
workload. I, on the other hand, am
able to see that you are not working effectively even if you cannot. Therefore,
I must be smarter than you (as well as
having more authority and status).
˲ If we were smart enough we would
recognize that we aren’t working smart
enough. And if we were smart enough
we’d be able to identify the smarter
way of working and we’d also figure
out how to transition from our dumb
way of working to the smarter way of
˲ Therefore, if we weresmartenough
to figure out how to work smarter, we’d
already be doing it. Clearly, we aren’t
smart enough to work smarter.
Much of the
The Cliché: “Quality is the
business of software
discovery of what
we are supposed to
Most important Thing”
Many organizations make this statement. Some of them even mean it. Of
those companies that mean it, a few
even act like they mean it. Software is
a knowledge storage medium, so a defect is simply a lack of knowledge—it
is something that we, as developers,
did not know or did not learn and
therefore didn’t build into the system.
So this exhortation is rather like the
“work smarter” cliché.
A defining characteristic of modern software development is that the
needs of the system change at close
to the speed at which we can build the
solution. So there may be nobody who
can definitively, and in advance, determine what “perfect” is. Developers
may be held accountable to a standard
that no one can define.
There is some perfect system representation that the developers should know
but through a combination of failings
(sloppiness, ignorance, laziness, ineptitude), developers have chosen to
not achieve this perfection, and need
to be reminded that it is important.
This perfection can also be achieved
without compromising any other of
the “most important” attributes of the
system (such as time and cost).
˲ Just what is “quality” and who can
provide us with unequivocal guidance
on it before or while we build the system (as opposed to second-guessing it
after the event)?
˲ Are we prepared to actually do
what we need to do to obtain the quality we say we need?
˲ If we delay delivering the system
because of quality issues, then the system is 100% defective (not one part of
it works, because the customer doesn’t
have it). Is this solution in the best interests of the customer?
Quality, along with all the other attributes of a system, is part of a balancing act. We might deliver higher quality
at the cost of delayed delivery or higher
cost or reduced functionality. Attaining higher quality is not a matter of
just stating the goal; it usually involves
discipline and hard work. And sometimes it involves difficult choices.