Warning: Rant.
Many of us who try to help organizations and teams improve the way they carry out software development and delivery work encounter a bizarre response from clients on occasion: “Your suggestion may work in an ideal world, but it can’t work in the real world.”
Why bizarre? Because they are experiencing challenges in their work and they have engaged outside helpers to advise them, and yet they dismiss the helpers’ advice out of hand. If all they intend to do is continue working in the same way as before, and claim that nothing will work “in the real world,” why do they bother to spend time and money to engage outside help?
Many people assume the advice we offer was just made up on the spot, or represents some academic theory that hasn’t been tried in the field, or requires the organization to be perfect even before they can try to implement the advice. In reality, the things we suggest are not new.
Some of the suggestions we make date back at least to the 1940s and the work of W. Edwards Deming, and ideas and models that grew from that early work either directly or indirectly, including well-known examples like The Toyota Way and Lean Manufacturing.
Some suggestions apply statistical or mathematical models relevant to software delivery work flows, like Network Queuing Theory, which applies in many areas besides software delivery, including such disparate activities as managing a customer service desk or operating a railroad system. Some advice is based on Empirical Process Control, which is relevant to a product development process such as software development, in contrast with Statistical Process Control, which is relevant to an assembly-line operation (which software development is not).
On the “human side” of the equation, some suggestions are based on studies of human behavior, psychology, sociology, and organiztional dynamics that have been around for decades. The idea of “humane workplaces” is decades old. People have been rebelling against the Tayloristic approach to management, especially with respect to white-collar occupations, for many years, although most large corporations still operate according to that model.
On the “technical” side, there are really not so many different suggestions, and all of them are practical, field-tested (actually, developed under real-world delivery pressure and organization constraints, rather than invented in an ivory tower). They fall into the general categories of (a) automation, (b) software engineering principles, and (c) effective teamwork.
Some commonly-recommended practices date back to the 1960s, such as static code analysis, which grew from the work of Mararet Hamilton on the Apollo project at NASA (what she called “higher order software”).
We often recommend principles of software design also dating from the 1960s, and documented in the proceedings of the two NATO software engineering conferences in 1968 and 1969, still relevant to this day.
Team collaboration techniques have been around a long time, as well; the US Army experimented with a form of collaboration in software development that we now call “pair programming” in 1975. The contemporary practice of “ensemble” work or “mob programming” was discovered in the field, in the real world when a team led by Woody Zuill needed to try something different to break logjams in software delivery.
Kent Beck began to imagine more-effective ways to build software as early as 1980; eventually that line of thought led to the practice we now call “test-driven development,” and other useful practices such as delivering solutions in small increments and performing incremental refactoring while developing software, to avoid the accumulation of technical debt.
The results we achieve come directly from the actions we take. When a software oganization is not achieving the results they desire, continuing to work as they did before will only result in the same outcomes as before – outcomes that do not achieve the results they desire. And yet…”that won’t work in the real world.”
There is no such thing as an “ideal world.” That’s a nonsense phrase and intellectually lazy. All the suggestions you hear from your external helpers were developed under real-world conditions by people who had to solve practical problems…people who could not afford to continue doing the same things they had been doing; people who needed to find and use effective methods and practices.
All these things that can only work “in an ideal world” are, in fact, those methods and practices. Some of them may help you, but you can only discover which ones – and how to adapt them to your context – through experimentation. If you refuse to try them, then you are creating your own problems.
The “real world” is what we create through our actions day by day, hour by hour, minute by minute. It doesn’t have to be a nightmare. That’s a choice.