FROM THE ARCHIVES OF PRAGPUB MAGAZINE FEBRUARY 2011
Ten Down, A Thousand to Go
By Andy Hunt
From Agile @ 10: Ten Authors of The Agile Manifesto Celebrate its Tenth Anniversary
We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.
Edsger W. Dijkstra offered that sage advice nearly forty years ago, at the conclusion of his Turing Award lecture in 1972. Apparently, as an industry, we’re slow learners.
The ensuing programming languages over the years, from Modula 2 and Ada to Java and C#, were neither modest nor elegant. Instead of respecting and working with our innate limitations, methodologies seemed to assume that people could make great decisions despite a complete absence of fact; that we could could plan months and years in advance with prescient clarity; that we could create working code that would, as if by magic, answer every need of an unseen and unknown customer. We thought we could even write code that did what exactly what we intended, more or less the first time. Well, at least as soon as it compiled successfully. Maybe with a few print statements for good measure.
Time passed, and some thirty years after Dijkstra’s gentle polemic, the Agile Software Development movement reached critical mass in Snowbird, Utah. The seventeen of us interested parties who gathered on that date had different views on how software development should best be conducted, but tacitly agreed on one very important point: the need, as Dijkstra put it, to respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.
A bunch of us (for some large value of bunch) recognized what it meant to be “humble,” in the sense that Dijkstra meant it. To take small bites, and not try and do too much at once, or to try to prognosticate too far out. To verify and validate what we’d written, not trusting our own overrated coding prowess. To openly and honestly discuss what we’d do next, not assuming that we knew better than anyone else. We recognized that software development is like trying to run through a very large dark cave with a very small weak flashlight. Raw speed will just kill you faster if you’re headed over a steep cliff.
Now, exactly ten years to the month after the catalytic coining of the word “agile,” where do we stand? Did the world at large catch on that programming was a might trickier than it seemed, and that you needed the support of modest and elegant tools, flexible and adaptable methods, and experienced, enthusiastic team members and customers in order to succeed?
Not exactly.
Meet the New Boss, Same as the Old Boss
Let’s start with education. Or rather, the lack of it. The better software engineering techniques promoted by agile methods still aren’t widely taught in college and university. There are some bright spots, and some excellent programs that actually “get it,” but we’re far from universal acceptance. There are plenty of degree programs where graduates have never worked in teams, never used version control, and never written a unit test. So academia isn’t quite on board yet. What about the corporate world?
Last summer, I had the good fortune to visit a “very advanced” agile shop. These folks really did embrace agile methods with a discipline, completeness, and a zealous fervor that would be hard to match. In many ways, they could have been a poster child for agile methods. For such a magnificent, large-scale operation to succeed, perhaps we had won the war after all. Perhaps the agile ideals really had taken hold, and manifested themselves here in this largish company, freed from the shackles of mindless dogma that had held previous generations of programmers in thrall.
But these weren’t productive developers freed from mindless process dogma. They were agile slaves. The dogma they followed was ours, and they followed it well. And as with many organizations in a similar position, they saw some promising results. Continuous integration, refactoring, unit tests, pair programming — all these techniques yielded some benefit. But they weren’t thinking, they weren’t reacting, they weren’t being agile. When problems came up, they addressed them with all the grace and elegance of a deer caught in the terrifying blaze of alien headlights. They knew how to do agile; they didn’t know how to be agile.
And that’s part of the continuing challenge. We’ve made great headway in getting better basic techniques adopted. Years ago you still found shops that didn’t use any version control system at all — just source code files on a shared disk, and “last one in wins.” That’s much less common now. Unit testing and its descendants are increasingly accepted and practiced, and even pair programming, often viewed with malignant suspicion by facilities managers and stakeholders alike, isn’t quite as foreign and scary as it once was.
But folks need to understand what it means to be agile; how to successfully solve the new problems that arise constantly. There’s no formula for that, and never will be. As Dr. Patricia Benner puts it so eloquently, “Practices can never be completely objectified or formalized because they must ever be worked out anew in particular relationships and in real time.” That’s a big part of the picture we haven’t got quite right yet: helping people work out new practices in particular contexts that work well for them. That’s the secret to real agility; it’s not about doing pair programming, or having stand-up Scrum meetings. Anyone can dogmatically follow the practices prescribed by others.
But true agility goes beyond the dogma, beyond the practices. Agility is about adapting; adapting your process, your language, your tools, your team, and yourself to respond to the situation at hand. We need to be positioned to be able to do that in order to fully realize the promise of agility, and maybe even move beyond it.
Beyond Agile
So what’s next? I humbly suggest we take the direction for the future from Dijkstra: stick to modest and elegant programming languages, and acknowledge and respect the intrinsic limitations of the human mind.
Java is neither modest nor elegant. But what about Ruby, Clojure, or Erlang? Are these languages modest or elegant enough? Can we come up with better programming languages, languages that make it easy to do the right thing? How many programming languages do you know? If it’s only two or three, grab another dozen before you answer.
As far as our limitations go, I’ve hit on a few of those in the PragPub “Guru Meditation” column (named for the old Amiga OS error messages.) Our brains aren’t wired optimally for this sort of work in general, and not well for agile methods in particular. But that’s just a start. Here are a few other interesting topic areas that we could pursue to go beyond agile:
- The Dreyfus Model. Experts are not merely smarter novices. There are many changes on the road from novice to expert, from how you approach problem solving to how and what you communicate. Yet on most teams, we tend to treat all team members equally. This is unfair to both novice and expert, in different ways. We can be more effective by using the lessons of the Dreyfus Model of skill acquisition to guide teaching, learning, and teamwork.
- Communications. In the 2011 State of the Union address, President Obama spoke of education, competitiveness, and inspiration. But the number one word that listeners heard? “Salmon.” The president made a joke about overlapping government responsibilities (which involved salmon), and that’s what stuck with the audience. People don’t always hear what you want them to hear, and we don’t communicate requirements, technical needs, or opportunities all that well. We can do better. From interviewing and working with users to help them determine their needs, to teaching the dangers of technical debt and the need to refactor, we can use what we know of cognitive limitations to communicate the important stuff more effectively.
- The Nature of Thinking. But improving communications is just the tip of the iceberg. We can improve our creativity and inventiveness — two critical components for successful software development. I touch on these topics in Pragmatic Thinking & Learning, but that’s only a start. A lot of the research in cognitive- and neuroscience can be applied to improve software development and other “thinking” professions. So far, we ignore most of it, because some of the lessons seem counter-intuitive to what we’ve been taught. But our brains are plastic and pliable, so we can change how our brains work, for better or worse. Let’s deliberately try for better.
Something to think about.
If you enjoyed this article, be sure to pick up a copy of Pragmatic Thinking & Learning: Refactor your Wetware by Andy Hunt:
About the Author
Andy Hunt is a programmer turned consultant, author and publisher. He
co-authored the best-selling book, The Pragmatic Programmer, was
one of the seventeen founders of the Agile Alliance, and co-founded the
Pragmatic Bookshelf, publishing award-winning and critically acclaimed
books for software developers.
