Slow software
Jeff Patton writes an article on Slow Software and puts it in context on his blog. He asks for reactions.
My off-the-cuff reaction is that he’s letting us ignore reflexivity. “Reflexivity“: a jargon word. What does it mean? Take two statements of Jeff’s:
Before we plan and build, we should
take time to understand what value is.
Make sure the first thing we gather is
how the people paying for the software
will get value from it. […]We also might want to understand
better the people using our software.
They’ve got goals, too, which likely are
met using other software or manual
processes today.
“What value is” and “their goals” and “their processes” ought to change when the software is injected into the mix. That change ought to reflect back on the product, which will then change its environment again, …, until eventually things settle down because further change is not worth the effort.
But I have to admit that reflexive loop is something that appeals to my personality. A perfectly valid response to the above goes like this:
-
The vast majority of products don’t need any high-falutin’ reflexive loop. They’re a CRUD app attached to a database, just like a zillion others.
-
I’m overly fond of this reflexive loop because I don’t have the skill to understand its value and user goals until after I dump a product on someone. If I were more skilled, I could immediately get to the same place that I today can get to only after several trips around the loop. Maybe, especially with those CRUD apps, I could even get immediately to the place where further change to decisions is not worth the effort. In that case, the main point of developing in short iterations would not be to allow discovery but to enforce discipline.
I think those are valid points. For that reason, I’ve asked Jeff to let me join him on some consulting gigs, so I can sit at his feet, watch, and learn.