What does “late as possible” have to do with writing software?

I'm late, I'm late, for a very important date... no time to say "Hello" - "Goodbye"!

Over 90% of all projects finish late… according to one survey.

25% or more are delivered late… according to another.

Over 30% are late or over-budget… and so on.

We know what “late” means when it comes to software and IT projects, right?

…maybe not when it comes to Lean Software Development.

From XP to lean

By this point, if you are a frequent reader here you know that my thinking about agile development stems more from XP than SCRUM, though I have a pretty open interpretation of methods either way.

I also have an undergraduate minor in production and operations management, so Rafael Tolotti’s post a couple of weeks ago about his experiences on a Lean Software Development project triggered me to look more deeply into it.

I was especially interested in the notion of “deciding as late as possible”, #3 on Rafael’s list. So I followed his link (to Wikipedia, btw), which led me to other sites that had greater background.

Without adding too much history to this post (which you can find out as easily as I did), Tom and Mary Poppendieck literally “wrote the book” on the subject, so I am going to accept and refer you to their site as authoritative for the purposes of this post.

Anyway, the site speaks of this principle a little differently, as follows (currently under the heading “Learn Constantly”):

Last Responsible Moment
Learn as much as possible before making irreversible decisions. Don’t make decisions that will be expensive to change before their time – and don’t make them after their time!

[Incidentally, of the seven principles listed on Rafael’s Wikipedia reference, Poppendieck’s “Keep Getting Better” isn’t listed… it was apparently replaced by “deciding as late as possible”.]

It’s our responsibility

Sorry for the cheesy pics in this post... I was more concerned about the writing this time.

I have decided I like these distinctions, so of course I will adopt and adapt them in my use of life’s salad bar… while I continue to do some more research.

One thing I really like is the use of the word “responsible” above.

Responsibility requires that you accept being the cause of an outcome from the decisions that you make, for good or for bad. (Here I am not specifically speaking in a moral sense.)

If you decide too soon, without enough information, you might guess right – you are more likely to guess wrong – but you are responsible nevertheless. If you decide too late… well, you are responsible for that, too.

That, to me, is not the same as deciding “as late as possible”.

Rafael’s meaning

Still, it was Rafael that led me into this thinking. I am sincerely thankful to him for the gift of introducing me to new thinking, and I hope I do the same for you.

So let me make some interpretations about how Rafael’s assertion provided significant and powerful meaning for me.

As I think through all the projects I have worked on, there were some times we made decisions too late. Sometimes it appeared we made decisions at the right time.

But I think most of the bad decisions came with too little information and we might done been better by just waiting for a season.

I see two counter-arguments here:

  1. If pressure is to get to market quickly, we feel there is no time to decide… so we have to do it quickly
  2. If we have a concern for the foundation we build upon, we may want deeper insights and need to learn before deciding

But high throughput of business value is a key objective of agile development. So it makes sense that many agile projects lean toward #1 over #2 (no pun intended).

Given the cultural predisposition on an agile team to keep plowing ahead, I can see how the original principle of Last Responsible Moment could become “Deciding as late as possible”… and I can see how the latter might resonate better with a pragmatic team of developers.


So, how do I resolve all of this? I am going to use both, but keep up the knowledge of the powerful underlying distinction from its source.

As for you… do you see the different between “responsible” and “possible”? Put that way, maybe it seems more straightforward.

What do you think could be the real impact of one principle or the other on the way a team thinks and the way it works together? How might the different philosophies show up in the code?

That which can’t be tested doesn’t exist… or must it?

That which can't be tested...

When I first read Martin Fowler’s Refactoring: Improving the Design of Existing Code, I stumbled on the phrase “That which can’t be tested doesn’t exist.”

In the years that followed, it has been something of a mantra to me, though I’ve found many things that made testing simply impractical.

What I want to do in this post is flip my earlier quote ON ITS HEAD!

Here’s a new category for ya!

In the category of not-really-a-corollary-but-it-makes-your-head-spin-to-think-of-it (dare me to add THAT to my blog categories!), Martin Weigel wrote in Restating The Wearingly Obvious, “You can’t test what doesn’t exist.”

That is flippin’ AWESOME! What he calls “wearingly obvious”, he describes in much more detail to be somewhat of a side effect of common sense thinking that we have ignored (in his case in the advertising industry) for over 30 years!

Here are a couple of key quotes and ideas from his writing that I see as relevant to the software industry:

  1. The idea that we can test “rough ideas” allows people to “abdicate their personal judgement and taste”, in other words, to “pass the buck” – what happens to the agile project without Metaphor or increasingly refined requirements?
  2. “Until you actually have finished work you are not testing creative solutions” – Hmm… sounds familiar (but not the same)?
  3. “Incomplete ideas evoke rough, incomplete responses from people” – even though he is writing about advertising, isn’t it important that what we test in agile is “true”, and that the reliability of our tests is related to some notion of completeness in the scenarios we anticipate?
  4. “Any research is therefore as authoritative and as fallible as the individual judgements and opinions of those involved in the [advertising] process.” Amen to that!

From Martin's post: did he identify an Archimedles?

Software development is creative work

And then he ends with a couple of really great sentences:

“There is no methodology in the world that can remove the element of uncertainty from the development of creative work. However much some might wish that to be the case.

“All creative decisions ultimately involve a leap of faith. And that requires more than simple courage. It requires people with taste and vision. People with the imagination and sensitivity to think ahead and be able to picture what has not yet been created.

“If you are unable to grasp these simple truths, if you slavishly believe rough responses to rough work to be The Truth, and treat them as directives for creative development, if you are uncomfortable with the notion of taking a leap of faith… then you are not one of those people. And you are very probably in fact, in the way.”

Wow! I hated quoting so much of his material here, but my challenge is that you look beyond the advertising domain he is writing about and think about the implications to software development.

So how does this trigger you? Let me know with a comment.