Code Like a Fighter Pilot, Design Like an Engineer — and Measure What?
Code Like a Fighter Pilot, Design Like an Engineer — and Measure What?
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
- How do you measure 'agility'?
- Who should be worrying about 'agility' in a given project -- developers or managers?
Both questions have easy, unsatisfactory answers (1: cycle time; 2: both). But I'd like to probe a little deeper than bean-counter level and think about these questions from the point of view of design.
Now maybe too much up-front design is a bad thing -- at least for certain kinds of software (e.g. consumer-facing & small-scale). But engineering involves design at every stage of development. The question is just how much and where.
And in fact some of the most extreme cases of up-front design – large-scale military, manufacturing, aerospace – jumped on 'agility' almost before anyone else. If this seems counter-intuitive ('how can factories fail early any often??'), read on.
Agile in 1991: responding to uncertainty
Well, of course the 'agile' buzzword is a lot older than the Agile Manifesto. Government and industry have been bloviating about 'agile' since at least 1991, when the Iacocca Institute compiled and discussed vast swaths of research under a US Navy contract, publishing the results as 21st Century Manufacturing Enterprise Strategy: An Industry-Led View.
This 1992 paper by Rick Dove summarizes the state of the buzzword one year later. Even the briefest glance at the bottom of page 1 will show you that swirling buzz-talk about 'The Agile Enterprise' pre-dates the Agile Manifesto by a decade. Dove observes that 'The Agile Enterprise' must contain systems that:
"..must be structured to allow decisions at the point of knowledge, to encourage the flow of information, to foster concurrent cooperative activity, and to localize the side-effects of sub-system change."
Sound familiar? Sure, these principles flow naturally from good software practices (separation of concerns! modularity! robust namespaces!). But the basic motivator for this early, manufacturing-and-military-centric concept of 'agility' was the astonishing success of 'lean' manufacturing in 1980s Japan. The basic need for enterprise agility comes from the same features of the modern world that modern software itself is designed to respond to: unpredictability, uncertainty, risk, and variation.
The history of the importation of the enterprise-centric picture 'agile' into the world of software development -- and the deep early conceptual rifts between (1980s Japanese) 'lean' and (1990s American-as-planned) 'agile' manufacturing -- is fascinating in itself. (Basically: lean is mean and agile is forgiving. Which you probably knew already.)
But agility -- in the sense of 'responding to uncertainty', not 'shortening cycle times' -- didn't deeply affect the enterprise until software developers led the way.
Government and manufacturing developed the concept, and yet developers often feel -- and in so, so many cases, this feeling is obviously spot-on -- that their non-technical managers don't really get it (however much they buzz the word). Why?
This is (partly) what I was trying to figure out in Seattle.
I have a few initial thoughts. For one thing, it seems to me that the early manufacturing-level literature on 'agile' doesn't articulate iteration nearly as explicitly as developers do. (This is understandable -- military and manufacturing can't pivot very quickly, because ships and factories are gigantic and incredibly expensive.)
But even Royce's classic 'waterfall' paper strongly emphasized the need for iteration between successive steps (and was written from experience building software for massive aeronautical projects at Lockheed). [Royce was saying that iterative-free, purely linear development doesn't work.] That's over two decades before Scrum. But Royce introduced iteration to avoid from-scratch redesign in the face of failure to meet external requirements -- not specifically to respond to uncertainty.
Contrarwise, consider the famously iterative OODA loop, also developed by the military, with the aid of software, specifically for fighter pilots, in order to deal with the radical environmental uncertainty generated by enemies trying to shoot you out of the sky.
Agile in the 1970s: closing the OODA loop
You've probably heard about the OODA loop -- Observe, Orient, Decide, Act -- and how it was developed (partly by computer simulation), who it was developed for (fighter pilots and designers), why it was developed (because Soviet-built fighters were surprisingly effective against 'more advanced' American fighters in Vietnam), and maybe some of its immediate effects (revivification of the F15 program; development of the F16).
You may also have read some of Boyd's musings on the philosophical underpinnings of the concept (note the considerable conceptual overlap with Ken Schwaber's initial paper on Scrum -- and the centrality of uncertainty). A bit further afield, you might find a bunch of exciting thoughts in Boyd's massively influential Patterns of Conflict. (Briefly: rapid pivoting confuses enemies; you can win by getting 'inside' the enemy's OODA loop.)
Like the early pictures of the Agile Enterprise, Boyd and Schwaber both focus on uncertainty. But uncertainty is a feature of the environment. Given an uncertain environment, the most important factor on the part of the agile enterprise/developer/pilot is time. If you can't predict how the environment will change, then you better be able to respond quickly when it does.
As a result, Boyd's preferred fighter was the F16 (for its maneuverability), and metrics like cycle time have received a great deal of well-justified attention in the world of ALM.
Agility vs. speed - the line strikes back?
But speed isn't quite what the fighter pilot needs. More important than straight-line speed is the rate of change of direction. Agile jets and agile codebases change direction quickly; they don't just move fast. The distinction is straightforward in concept, of course, but all too easy to miss in practice.
The reason is partly a function of technical psychology: flow is good, and immensely satisfying. And the whole point of a flow is that Boyd's O and O are completely invisible. There's just D and A, and of course you're Ding and Aing correctly every time.
But every part of a laminar flow moves in one direction. A speed-maxed laminar flow needs to slow down in order to avoid turbulence during unexpected shifts in direction. To me this feels like a certain kind of coding. Anyone who has buzzed their way through a cowboy-dev session knows the feeling. The code is flowing thrillingly, but the momentum vector is getting too big to change.
Even assuming no technical debt (because you're totally in the zone, you're not taking shortcuts, everything is coming out just perfect), the straight-line productivity might be advancing too fast. At least, too fast to respond to uncertainty -- maybe fast enough to skip the first to O's. Maybe 'hurtling' is a good word.
(Paul Virilio thinks that the failure to distinguish straight-line speed from rate of change of direction is endemic to the entire modern world. I don't know how true that is, but I do understand the feeling, especially while 'in the zone'.)
What do you think?
So I wonder whether too much emphasis on cycle time, or time to market, or other purely straight-line-speed-focused metrics are perhaps offering 'straight line' thinking a little revenge over our lovely Scrum iterations. Cycles let you reorient; retrospectives close your OODA loop and prepare to open the next. And if you don't ever close the loop, then you're just in one huge loop and your enemy will shoot you down...
We'll talk more about methods and solutions later. DevOps is a start, but ops considerations aren't the same as good design-level engineering (which needs all four stages of the loop). Smarter user acceptance testing is probably another; and static analysis needs to fit in somewhere, because the real driver of software agility is the code itself. (I also have a feeling that trees are going to prove annoyingly helpful..but I'm not sure.)
But right now I'm trying to figure out what metrics can really be used to measure your agility rather than speed -- that is, the rate at which software developers (and projects) change direction to respond to the unexpected and uncertain.
And I'd love to hear what you think.
Are pure-speed metrics harmful, neutral, helpful, meaningless, and if so how and why? Let's assume (unrealistically) that there is no technical debt -- because we're trying to measure degree of agility, not degree of perfection.
How would you measure software agility in the sense described here -- as the rate at which software developers (and projects) change direction to respond to the unexpected and uncertain?
Opinions expressed by DZone contributors are their own.