Max Guernsey, III

It's a real book .

Now... that this book exists is not that strange.  My question, though, is as follows:

Who else would it be for?

There was a feathered serpent in ancient times.  He traveled around the globe in a ship that could cross the sea, the sky, and even take him to the heavens to visit the intelligences who lived in the stars.  Wherever he went, he sewed the seeds of culture. He taught of astronomy, agriculture, sanitation, language, and mathematics.  He left behind pale-faced servants to oversee the construction of great megalithic structures which were, themselves, embodiments of the knowledge he carried.   Everything we are today, we owe to this being of proto-history.

Does that sound implausible to you?  It may, in fact, just be a myth that was believed by many an ancient tribe.  It may be a folk memory of something a lot more mundane.  It may be true.

Whatever the case, it is about a million times more probable than what a lot of contemporary professionals in the software industry believe today.  The notion of "test-driven development," has proliferated in such a way as to create a myriad "X-Driven Development" distinctions with, at most, only minor differences.  I'd like to explore another "X-Driven Development" that is truly different from what modern developers with full skill-sets practice today:

Myth-Driven Development (MDD)

At first, this notion was a joke.  One of the many quips I snapped off at people who don't want to take what we do seriously.  Over time, I came to realize "No.  This really is how these people think."  Many software developers are the modern-day equivalent of superstitious savages who believe that the sun disappears because the gods are angry with them.

Let's debunk one myth at a time, starting with Bugs.

So what is a bug?  I think that examining the definition of a bug will help us to eradicate the concept from our minds.  Let's go through one definition at a time.

Definition 1: When software does something it shouldn't do or should do something it doesn't do

The problem here is the definition of "should."  How do we know what software should have done?  How did it get to the point where it does something other than what it should have done?  Is a missing feature a bug?  Are all potential features bugs?  This definition is simply too imprecise.

Definition 2: A behavior that the customer expects but is missing or is present but the customer did not want

There are two really big problems with this definition.  One is that most software has different customers and, generally, they have different wants.  Almost without fail, one customer's bug is another customer's feature.  So we have the problem of perspective.

Also, there is the problem that no software package ever does everything that even one customer wants.  So, the moment a software product is released in an Agile environment, it has a bunch of "bugs" which map directly to items on the backlog.  You could argue that any feature which is not on the backlog would then be a bug but that pretty much defeats the entire purpose of having a backlog.

In order for this definition to work, you have to have some way to resolve conflicts.  One option is to go with something like a specification, which is handled in the following definition.  The other option is to go with the "obvious answer," which is pure fantasy.  

Definition 3: A behavior that was specified but is missing or was not specified but is present

This is a fairly reasonable definition, actually.  There are only two issues.

Firstly, there is the fact that you can't really distinguish between work that is not yet finished (say work for the current sprint) and a bug by this definition.

Secondly, there is the fact that, with the exception of work in progress, this is a one-hundred percept preventable scenario.  "Not possible," you say?  Wrong.  It is completely possible.  If all of your specifications are executable and you cannot release software for which one of your specifications is complaining, then you will never release a "bug."

If a bug cannot get released then what is the purpose of having it?  Mainly, to keep a "to-do" list of things that need to get done in order to release... but your bed of executable specifications (your tests) already provide you that "to-do" list in the form of failing tests.  This list will always be in-synch, without anyone working to keep it up to date.

There is no good definition

The problem with the word "bug" is that there is no good definition that can distinguish it from something better, like a failing test or an unfulfilled story on a backlog.  Definition #1 is more or less impossible; software always does what it should do because what it should do is exactly what the programmer told it to do.  Definition #2 is based on the deeper myth that there is such a thing as "obvious."  If the word "obvious" could be banned from the dictionary, I think we'd all benefit.  Definition #3 is not unreasonable.  However, if you accept definition #3 as your definition of a bug and you adopt modern software development practices such as TDD, then bugs can exist only as hypothetical structures there should be no documented, real-world cases of a "bug" discovered in the modern era.

As I was working on the course book for my course on how to achieve Database Agility, I noticed something: a lot of good design practices map directly to Lean principles.  Not just that they are consistent with them; certain practices are actually instantiations of Lean principles in the small.

I'm not claiming to be the first one to have discovered this.  It is just the first time that I have ever thought of or heard this.  So let's look at the first principle: value.  What does "value" mean?  It means a lot of things to a lot of people but, to Lean thinkers, it has a very specific meaning: value is something a customer wants or needs.  In other words: we start by figuring out how we can fulfill a need, then work backwards from there to build a product.

How does this map into software development?  One obvious practice that comes to mind is programming by intention, a.k.a. "top-down programming." Programming by intention runs deep in Agile software development.  It is part of test-driven development - in fact it is most commonly done as part of that process - it is part of refactoring.  It is part of a lot of things.

We come up with all of these terms for why it's a good thing to do.  For instance, people say "programming by intention is good because we are defining classes from the outside in."  Another common way of putting it is "programming by intention is good because a class or method is designed in the context of the need that caused it to be made."

If you consider clients to a class or method to be that artifact's "customers," then what you are really saying is "programming by intention is good because we are defining classes from the outside [where their customers are] in [where the service provider is]" or "programming by intention is good because a class or method is designed in the context of the value that it creates."  Both of which are just fancier ways of saying what Lean consultants have been saying for a long, long time...

Principle #1: start by identifying value.

Up next, we'll see how Principle #2 (define the value-stream) maps to software design.

1. Attempt to improve your own scores - widening or narrowing the score gap in your favor.
2. Work against your opponent - defending the score gap.
3. Do nothing - acting has a cost so wait for an opportunity.

There are two lessons to be learned from this game:

• Carefully define and work toward value.
• Favor a little value now over a lot of it later.

Both of these lessons also depend on the notion of position.  Your position is constantly changing as a result of another actor working it its own self interest.  This can be thought of a micro simulation of market forces.

On Value

This game has some very interesting principles that make it necessary to work on value rather than taking a large number of essentially blind actions some of which yield value.

Every ball you fire has a cost.  Like programming, there is a small cost to firing each ball and, also like software development, each action carries with it the risk of changing your position for the positive or the negative.  The amount of impact that each shot has on your position and your score can vary greatly.

Consequently, I've found that option number 3 (hold your fire) is more valuable than originally would have seemed to be the case.  By firing selectively, I am biasing the impact that each shot has on my score and/or position toward the positive.  This is just like product development.  Only developing those features you need yields far greater profitability than blindly developing everything you can think of.

On Prescience

Many of you probably also know that I have a product called GuideWire.  I and many others use this product to help me plan my shots when playing this kind of game.  One of the features of this tool is that it gives you the ability to predict how a ball will bounce off of a wall, as shown in the picture below...