This tweet resonated with me:
The comment applies to the author’s area of focus, but the pattern she observes occurs broadly in our field. How is it possible circa 2019 that the majority of people in the software field are not routinely using:
- rolling-wave planning to avoid premature investment in undeveloped ideas and to enable business flexibility/agility?
- flexible funding models to avoid locking up funds in early, long-term budget allocations?
- product-oriented experiments to steer development work toward target capabilities, as opposed to a portfolio of projects with rigid, predefined objectives and timelines?
- collaboration with stakeholders, Specification by Example, Personas, Story Mapping, etc. to understand user needs?
- cross-disciplinary collaboration to build solutions, including cross-functional teams, sitting together, swarming, mobbing, pairing, etc.?
- development techniques that yield multiple forms of value for a single effort, such as test-driven development and test automation, both for infrastructure and for applications?
- general automation to reduce errors and ensure consistency, such as continuous integration, static code analysis, dynamic infrastructure management, etc.?
…and, of course…
- observability rather than monitoring?
Do people actually prefer
- high stress?
- misalignment with user needs?
- errors and defects?
- long lead times?
- low throughput?
- more high stress?
- monolithic and tightly-coupled software solutions
- incomprehensible source code?
- low predictability?
- configuring snowflake servers by hand?
- late nights tracking down problems?
- even more high stress?
And if they don’t prefer those things, they why do people defend them so staunchly?
Mastering A before trying B
This part of the tweet resonates especially: “…my team isn’t there yet, they’re just learning basic monitoring. Maybe someday, after they’ve mastered that…”
How many times have we heard the same refrain, those of us who try to introduce simpler and more-effective ways of doing things? “Our teams aren’t ready for Kanban. They have to master Scrum first.”
Do they, really? Well, then, what makes you think they’re eligible to try Scrum, when they haven’t mastered RUP first? And what gives them the right to try RUP? Did they master Objectory first? And before they were allowed to try Objectory, were they required to master Spiral? And how dare they try Spiral before mastering V-Model?
Why are we allowed to drive cars before we’ve mastered horseback riding?
It’s like the 1980 movie, Altered States, in which Edward physically devolves through the use of hallucinogenic drugs and a sensory deprivation chamber, until he’s on the verge of transforming into nothing at all. How many ancient techniques are we required to master before we’re “ready” to use the latest methods and tools in our work? Must we devolve all the way back to primordial nothingness and then repeat every step our ancestors took?
The thing is, in all these cases there has been an evolution of methods. The newer methods tend to be improvements over older methods. If a newer method proved not to be an improvement, then you haven’t heard of it because people stopped using it. The details of the newer methods tend to be remedies for problems people experienced in using the older methods for real work in the field.
It isn’t as if some academic is trying to cram a half-baked theory down our throats. RUP is easier and more effective than Spiral. Scrum is easier and more effective than RUP. Kanban is easier and more effective than Scrum. There’s probably someone out there making further improvements, and whatever they come up with will be easier and more effective than Kanban. I’m looking forward to it! I like stress-reduction!
It’s the same pattern for software development methods, too. Test-driving code at the microtest level is more effective than test-driving code at the component level. Test-driving code is generally more effective than writing tests after the fact. Writing tests after the fact is more effective than not writing tests. Recently, Kent Beck came up with another approach he calls “test && commit || revert”. Maybe it will prove to be an improvement over test-driven development. Maybe it won’t. There’s only one way to find out. Either way, evolution continues.
It’s the same pattern in Charity’s area of focus. Tools and methods based on the idea of observability are improvements over tools and methods based on the idea of monitoring. Monitoring production systems was an improvement over not monitoring them, and reacting to problems after they had become serious. Must we master the art of running in circles with our hair on fire before we’re “ready” to try something better?
Why would anyone not want to make their own lives easier and simultaneously improve the quality and effectiveness of their work?
“Yes, you’re right, the needles under my fingernails cause pain, but I’m accustomed to that pain. Don’t remove them, unless you can show me an academic study that proves I won’t experience even more pain without them!”
I’m glad I didn’t go into psychology. It would have driven me crazy.