BlogRequirements

Is Doing More Important Than Thinking?

15.04.2015

geschrieben von

Gast

When I read one of Woody Zuill’s tweets recently, I immediately followed the link to his “Life, Liberty and the Pursuit of Agility” web site. I knew Woody from reading one of his articles about #NoEstimates. I liked it, because Woody had good points and left it open what could work best for me. So I was curious about his 8 Agile Maxims. While I got a general feeling that Woody and I are on the same side of the Force, Maxim 1 did not pass easily:

1 – It is in the doing of the work that we discover the work that we must do. Doing exposes reality.

I live this daily.  Thinking about stuff is obviously worthwhile – I don’t discount that. But doing is way more important.

These words confused me. If, talking about software development, doing exposes something that thinking doesn’t, what kind of doing is it, and what kind of reality does it expose? Is doing distinct from thinking? And what kind of reality can there be besides my thinking?

You must know that I am a requirements person. I was once a programmer called “software engineer”. Now I have a business card saying that I am a requirements engineer. (Senior, even.) But one of my big questions in life is whether what I do is engineering at all, and if not, what is it? This has a lot to do with my own experience with agile and with its overall success. But that’s a different matter. I’m telling you that I’m a requirements person because I think descriptions are important. You may say specification or requirement or model, I say description. The best book on the topic I know is Michael Jackson’s SRS book. I would like to quote two things for you:

  • A designation lets you clearly and unambiguously recognize a phenomenon in the domain.
  • Designations are not assertions.

I may have struggled with the assertion Doing exposes reality in a way thinking doesn’t because the phenomena thinking and doing were not designated. So let me try to designate them. I’ll start with thinking.

Thinking is a human activity that produces communicatable content such as ideas and thoughts. The produced content may or may not be communicated. Thinking is located in one human individual and not directly observable from outside.

And here is an assertion:

When a person is reading or speaking or writing, that person is thinking. (A1)

Since speaking and writing are observable phenomena, they also make thinking observable to other individuals.

Note that the assertion is a refutable description. If you can provide clear evidence that someone read or spoke or wrote without thinking, it is wrong. (Note also that assertions about thinking are a bit tricky in general.)

Now we get to doing.

Doing is any observable activity.

(I will not designate “activity”, or I might get lost. The point about designations is that they are good enough for you and me to recognize the phenomenon. If it serves that purpose, I don’t mind if you object that it is a tautology.)

Let’s explore this. According to the designation, all of the following are Doing phenomena.

  • The cat is sleeping.
  • John is looking out the window.
  • The engine is humming.
  • Lisa is explaining a property of the Client class to Marc. (e1)
  • Lisa is coding a method of the Client class. (e2)
  • Fred is documenting the class model as a UML diagram. (e3)
  • Marc is discussing how the company grants discounts to clients with the product owner. (e4)
  • Kathy is checking the status of client X in the production system. (e6)

However, the following are not, as long as there is no observable activity:

  • Fred is thinking about which events change a property of the Client class. (e5)
  • Fred is analyzing why an event in the business domain was not reflected in the state of the Client class. (e7)
  • John is analyzing how clients responded to discount offerings. (e8)
  • John decides to drop the user story about combining discounts. (e9)

(I will get back to the e_i phenomena.)

The second assertion I shall provide is Woody’s Maxim 1:

It is in the doing of the work that we discover the work that we must do. (A2)

It is meaningless without another designation:

The work (we must do) is any activity that contributes to building a machine by describing it.

(Note that the source code is a description of the machine. Yes, this is Jackson-speak.)

Talking and writing, in contrast, are observable, therefore doing. Due to Woody’s assertion

Doing exposes reality (A3)

talking and writing expose reality, and due to my A1 they imply thinking. Doing and thinking may happen in parallel, which is in sync with my understanding of the domain.

But according to my designations, I would classify discovery as thinking. Then what sense does it make to say doing is more important than thinking, if the purpose of the doing is to bring about discovery, i.e., thinking? Also, why would writing code or talking about the software expose reality in a way thinking doesn’t, when they just make thinking observable?

Okay, I know I’m getting lost in abstract considerations. Of course, a conversation with Woody would be best to clear things up. Starting point could be the following story:

As a pursuer of agility, I want to do the work in order to discover the work that we must do.

But I have a hypothesis. (Yes, more of the abstract considerations!) Woody’s Maxim 1 is about software complexity. In my words it states that

Chances are poor to develop a thorough understanding of a complex machine, including its behavior in the application domain, and discover the requirements that govern its construction, just by thinking about it, i.e., up-front analysis. By building at least part of the machine, putting it to operation and observing its behavior as well as user responses, they are far better.

That’s why agilists value working software.

Did I spend so much time in thinking about designations, writing them down, re-thinking and re-writing, and did I consume a fair bit of yours for reading, just to tell you that Woody’s Maxim 1 is probably his particular flavor of one of the agile core values?

Not quite.

Software development is about working your way from vague ideas to precise descriptions, the code being nothing more than an unambiguous description of the system. It is a lot about a good understanding of the application domain. States, events, and the order of the events matter when the software deals with a dynamic domain. Agile’s success is largely due to the fact that it acknowledges software development as being a dynamic domain, in which certain behavior observation events must precede certain discovery events. The behavior observation events in turn require delivery events. Your software development method must be able to respond to the discovery events and bring about a new delivery event which reflects the discovery event. For example, it may not be enough to make events e1 through e5 happen if e7 is required for correctness, and only e6 can make e7 happen. So e6 should happen as soon as possible. Also, e8 may have to precede e9, and many events of the “a client places an order” class may have to precede e8.

But wait: What does that mean, “only e6 can make e7 happen”? That’s just a prejudice. Yes. It is precisely one of the fundamental prejudices of Agile. Up-front analysis will fail to bring about enough of the necessary discovery.

I don’t know if my description reflects Woody’s understanding. It certainly reflects mine. Anyway, you saw how Jackson’s advice to describe the domain helps in relating the problem to a method that can solve it. What’s more important: “Thinking about descriptions is thinking about thinking” (M. Jackson, SRS, 1995, Chapter Descriptions). Well, you know, I just felt like doing that.