The biggest threat to success in software development is the Escalation of Unessential Complexity (EUC). Like stress is to humans, EUC is a silent project/product killer lurking in the shadows – ready to pounce. If your team isn’t constantly asking “how can we make this simpler?” as time ticks by and money gets burned, then your project and product will probably get hosed somewhere downstream.
But wait! It’s even worse than you think. Asking “how can we make this simpler?” applies to all levels and areas of a project: requirements, architecture, design, code, tools, and process. Simply applying continuous inquiry to one or two areas might delay armageddon, but you’ll still probably get hosed.
If you dwell in a culture that reveres or is ignorant of EUC, then you most likely won’t ever hear the question “how can we make this simpler?” getting asked.
But no need to fret. All ya gotta do to calm your mind is embrace this Gallism :
In complex systems, malfunction and even total malfunction may not be detectable for long periods, if ever – John Gall
Robert Pirsig’s “Zen And The Art Of Motorcycle Maintenance” is one of my fave books of all time. I have a soft cover copy that I bought in the nineties. Because of its infinite depth and immersive pull, I’ve read it at least three times over the years. Thus, when Amazon.com sent me a recommendation for the kindle version of it for $2.99, I jumped at the chance to e-read it and capture some personally meaningful notes from it.
(Published in 1974) the book sold 5 million copies worldwide. It was originally rejected by 121 publishers, more than any other bestselling book, according to the Guinness Book of Records. – Wikipedia
In a nutshell, ZATAOMM is about a college professor (Pirsig himself) who ends up going insane over his obsession with trying to objectively define what the metaphysical concept of “quality” means.
Quality…you know what it is, yet you don’t know what it is. But that’s self-contradictory. But some things are better than others, that is, they have more quality. But when you try to say what the quality is, apart from the things that have it, it all goes poof! There’s nothing to talk about. But if you can’t say what Quality is, how do you know what it is, or how do you know that it even exists? If no one knows what it is, then for all practical purposes it doesn’t exist at all.
During my fourth read of ZATAOMM, I started noticing how much of the wisdom Mr. Pirsig proffers up applies to the “art” of software development/maintenance:
When you want to hurry something, that means you no longer care about it and want to get on to other things.
This comes up all the time in
mechanicalsoftware work. A hang-up. You just sit and stare and think, and search randomly for new information, and go away and come back again, and after a while the unseen factors start to emerge.
Sometimes just the act of writing down the problems straightens out your head as to what they really are.
The craftsman isn’t ever following a single line of instruction. He’s making decisions as he goes along. For that reason he’ll be absorbed and attentive to what he’s doing even though he doesn’t deliberately contrive this. He isn’t following any set of written instructions because the nature of the material at hand determines his thoughts and motions, which simultaneously change the nature of the material at hand.
Any effort that has self-glorification as its final endpoint is bound to end in disaster.
Stuck. No answer. Honked. Kaput. It’s a miserable experience emotionally. You’re losing time. You’re incompetent. You don’t know what you’re doing. You should be ashamed of yourself.
This gumption trap of anxiety, which results from overmotivation, can lead to all kinds of errors of excessive fussiness. You fix things that don’t need fixing, and chase after imaginary ailments. You jump to wild conclusions and build all kinds of errors into the machine because of your own nervousness.
Impatience is close to boredom but always results from one cause: an underestimation of the amount of time the job will take. You never really know what will come up and very few jobs get done as quickly as planned. Impatience is the first reaction against a setback and can soon turn to anger if you’re not careful.
Impatience, stuckness, underestimation, anxiety, and carelessness. These are just a subset of the feelings and behaviors that pervade dysfunctionally soulless organizations whose sole focus is on “following prescribed process and meeting schedule“.
Me thinks that these two quotes go together hand in hand, and in the order presented:
“At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success.” – C. A. Hoare
“The bitterness of poor system performance remains long after the sweetness of low prices and prompt delivery are forgotten.” – Jerry Lim
Have you ever participated on a project that made it out the door but caused financial and social “problems” sometime downstream? Lucky for him, BD00 hasn’t.
In golf, when you shank a shot off the tee, sometimes you’re allowed a “Mulligan“. A Mulligan is a “do over” where everyone cheatingly agrees that your first shot never took place and you get to tee off again with no stroke penalty. As you might surmise, I love freakin’ Mulligans; especially when the agreement allows TWO Mulligans per 18 hole round. Whoo Hoo!
Like the bailed-out principals that ignited the world’s financial meltdown, it looks like the army and its contractor cohorts are getting a Mulligan with the cancelled, 15-year, multi-billion dollar JTRS (Joint Tactical Radio System) program. Everyone involved in the original shank shot gets to wipe the slate clean; the program gets a shiny new name (JTN = Joint Tactical Networks program) to shake off the prior stank; and the players can start gorging on taxpayer money again.
But of course, this next go around will be different – the approach will be “entrepreneurial” despite the fact that all the participants are huge command & control hiermalarkies.
In the software development industry, going too slow can result in nothing getting done in an “acceptable” amount of time and thus, impatient managers cancelling projects. On the other hand, going too fast can result in hackneyed designs, halted downstream progress due to lots of rework on an unmanageable code base, and thus, frustrated managers cancelling projects.
As the figure below shows, the irony is that going too slow can result in less sunk cost due to earlier cancellation than going too fast – which gives a false illusion of great progress till the fit hits the shan.
So, how do you “objectively” know if you’re going too fast or too slow? It’s simple: you freakin’ don’t. However, in a world increasingly dominated by “agile” indoctrination, faster seems to be always equated with better and the tortoise vs. hare parable is heresy.
This is one of those picture-only posts where BD00 invites you to fill in the words of the missing story…
The graphic below transforms the title of this post into a visual manifestation that can be discussed “rationally” (<— LOL!).
The graphic shows that pursuing any of the four path selections can lead to a “number 2” outcome. It’s just a matter of how much time and money are exhausted before the steaming pile is discovered. D’oh! I hate when that happens.
Obviously, the path to the holy grail is D->1. Simply take whatever info is known about the problem, code up the solution, get paid tons o’ munny, move on to the next problem to be solved, and never look back. Whoo Hoo! I love when that happens.