Stop Falling For Extreme Views
Take a middle-of-the-road approach by avoiding the extremes
Software development/delivery profession is still in its early infancy. Presently, we witness this profession suffering from childhood diseases that manifest as falling for two kinds of extreme views:
Know upfront what needs to be done, then divvy up the workload among team members and start cracking to meet the scheduled delivery deadline
Rely on the immediate feedback provided by the frequent delivery to guide the team in learning what to do next
Neither of the above two extreme views is helpful when it comes to providing quality work. The first view (also known as the waterfall approach) suffers from the type of arrogance that claims that it is possible to accurately predict the future. The second view (also known as the agile approach) suffers from the type of arrogance that claims that any time we make any change, immediate feedback is guaranteed.
We need to grow up and face reality. When making changes to an automated system, we cannot be sure of the outcome of that change. We first need to abandon our childish hubris in thinking that we understand the problem and know upfront what the solution to that problem is. Then, we need to abandon our childish hubris in thinking that if we switch to making small changes to the system, the thinly sliced change will immediately point out what our next step should be.
There are many situations where any change to an automated system will percolate through the system, will very likely leave the system and travel to some other systems, and will eventually travel back to our system and finally deliver some kind of feedback — an outcome. It is that outcome that we are always gunning for. Without that outcome, we stand no chance of learning anything. And as the saying goes, if everything goes according to our plan, we haven’t learned anything.
The clincher lies in the fact that the above-described process of interaction, where the change percolates throughout the system and then very likely also makes detours by visiting other, third-party systems, takes some time. That extra time may impose a price on our process, and we must be prepared to amortize for it.
Knowing that, we must not naively rely on the thinly sliced changes that are supposedly guaranteed to produce immediate feedback. And even if the feedback happens to be immediate, it may not be the optimal feedback; giving the process another chance, letting the users of the system take it for a spin around the block a few times, will most likely produce feedback that is different from the immediate feedback. And that delayed feedback is often the one we’re really looking for. So, it’s always worth waiting for it.
When developing software, we’re in for the long haul. Software is a living, breathing thing that needs constant nurturing. It needs both parents — the software team (the father), and the customers (the mother). Keep the following in mind: we cannot understand the problem before we try the solution.