I recently tweeted:
- An object may only be created once and only once. It may be removed, but then not created again.
- It must be possible to create an object with identical properties again and again.
I recently tweeted:
While I was recently working on some test automation task, I had the feeling that the automating of the tests seemed to be more important, than the actual automated tests (or checks) I created. It seemed to me that this is very similar to the saying that the planning in agile projects (and likely in other projects as well) is more important (or valuable) than the plan you get out of the planning. So I tweeted about it and within seconds Lisa Crispin agreed to this.
It seems to me there is a pattern—actually a question—at work: Is doing something more important than the result you get out of that activity? There’s a book by Mary and Tom Poppendieck ‘Leading Lean Software Development’, subtitled ‘Results Are Not the Point’, that hints in the same direction.
Is actually doing something really more valuable or important than the result of this activity? I’m not sure about this.
The result of having done something seems obvious: We have the result, something that didn’t exist before and has some value to someone (hopefully). But what about the value of the activity itself? Two things come to my mind immediately:
What do you think about this? What makes the doing itself valuable to you, apart from the outcome?
Let’s go back to the creating of automated tests: While I was looking at newly implemented parts of a software system, as soon as an automated test executes and yields a reproducible result… it’s a regression test (or check as some would say). Now, regression tests are not particularly likely to disclose new defects, so what’s the value of automating anyway. While I can’t offer a generally valid answer, the automation effort itself helped me to uncover a number of bugs.
Read in 100+ yo teach book: teacher should script lesson, then throw away script at class start. Scripting useful for prep, not instruction.
Another great example of the pattern.
One pattern I see often is that people (me included) apply more of some X, if applying the usual amount doesn’t yield the desired result (anymore).
Two examples from very unrelated fields:
So when X doesn’t work, or doesn’t work anymore, applying more of it won’t help. Alas reducing it (less/no shouting at the pet, removing process load from projects) won’t solve the issue.
It seems to be a lot more promising to try an entirely different approach. After realising issues with waterfall projects, we (as software developers) found agile methods to be helpful. In the case of training a dog it’s another way to help the dog learn a new command. In some cases it may even be necessary to teach it its name before.
Did you see anything like this? Let me know.