“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.

inferences

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.

Defense

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.

inferences

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).

Defense

˲ 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 working.

˲ 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
business of software
involves the
discovery of what
we are supposed to
be doing.

The Cliché: “Quality is the
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.

inferences

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).

Defense

˲ 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.