Thought I’d share an excerpt from Chapter 3 of our book “Effective UI: The Art of Building Great User Experience in Software“. By far, this the most definitive explanation of why enterprises need to reconsider how they’ve approached software development in the past. RFPs, Fixed Bidding, Waterfall, all have dangerous implications to the success of any software project. Many companies use the wrong analogies when planning projects; they plan using construction metaphors. This chapter does a great job explaining that in reality, planning a software development project should be more like planning a war.
—————————————————-
Uncertainty and the Unknown
Uncertainty and the unknown are enormous, unavoidable, and fundamental components of every software development project. Being at peace with this reality means you can approach the project in a way that adjusts and flows to account for the unknown. If you fight uncertainty and the unknown—or, even worse, if you suppose they don’t exist—it’s a path to defeat.
The mistaken belief that uncertainty can be entirely stomped out through upfront planning and everything can be known in advance is the root of many of the worst problems and errors in the management of software proj- ects. This arises from the misapprehension that software development is com- parable to and can be managed like other types of large-scale engineering proj- ects—building a bridge across a valley, for example. Bridge building and soft- ware development both have components of science and engineering, and of art and craftsmanship. But the role of uncertainty and the unknown, and the way science, art, engineering, and craftsmanship work together throughout the course of the project are very different. Those differences demand a fun- damentally different approach to management of the project.
The notion may seem discouraging, but it’s much more accurate to compare software development to war than it is to compare it to bridge building. While the battle of software development is fought more with electrons and Mountain Dew than bullets and napalm, the battlefield is a complex, dynamic, unpredict- able system of activity residing in shifting political and operational contexts.
The Humility of Unknowing
I am the wisest man alive, for I know one thing, and that is that I know nothing.
—Socrates
To demonstrate how uncertainty and the unknown are inevitable compo- nents of a software development project, we’ll examine why the bridge- building analogy fails and the war analogy succeeds. But even with the aid of analogies, it’s extremely difficult to explain why uncertainty and the unknown are unavoidable to someone who’s never been in the trenches of a software development project. Much of the understanding comes from see- ing how design, creativity, and inspiration factor into every aspect of build- ing an application. It also comes from having seen how false certainty, and the demand for it, can cause failure and lead to poorly designed products.
It’s difficult to explain or prove this fact except to state it this way for now: you understand your project far less than you think you do.
And so do your stakeholders, by the way. For your project to be successful, you need to cultivate in yourself and in your stakeholders a certain humility and a recognition that, for as much as you know, you know very little, and that the essence of the project is to investigate and solve a complex problem and not simply to implement a known solution. Embracing this humility of unknowing isn’t a resignation to defeat or admission of weakness, but rather is a state of wisdom required to allow you to succeed.
The Weakness of Foresight and Planning
The great uncertainty of all data in war is a peculiar difficulty, because all action must, to a certain extent, be planned in a mere twilight, which in addition not infrequently—like the effect of a fog or moonshine—gives to things exaggerated dimensions and unnatural appearance.
—Carl von Clausewitz, On War
Everything required to design a bridge to a valley is knowable in advance and can be planned to an extremely high level of accuracy before construction begins. All of the important goals, variables, and constraints can be accurately obtained before design begins.
Once those key considerations have been discovered, the design of the proj- ect begins and can be entirely completed before construction starts. With accurate and complete designs in hand, construction is then all about ensur- ing the pieces all come together as designed. Construction is not concerned with any remaining questions about the design and isn’t burdened by the risk that the design will change during the course of construction.
By contrast, a general preparing for battle can estimate the strength and disposition of his forces, the resources and capabilities available to him, the attitudes and aptitudes of his commanders in the field, the lay of the battle- field, the strategic goals of the battle, the state of the enemy’s forces, and the parameters for success. He also has history and personal experience to help him intuit how events will unfold. Based on this knowledge, he can formu- late a plan for the battle.
But this plan, no matter how carefully devised, is inherently incomplete and imprecise. It is wholly premised on estimates of the conditions before the battle and entirely ignorant of the unforeseen conditions that arise during the battle. These unforeseen conditions are based as much on the vagaries of weather, emotion, chance, and uncertainty as they are on even the best-laid plan. This reality is the basis for the famous quote:
No battle plan survives first contact with the enemy.
—Helmuth von Moltke
The same is true of software development. No matter how well you think you understand the domain and no matter how earnestly you’ve thought through the requirements, there is still great uncertainty in the original facts and premises and a vast depth of the unknown still awaiting you. As with battle, the outcome will be determined at least as much by what comes dur- ing the course of the project as by what comes before it.
Not all unknowns are bad, by the way; it’s in solving the unforeseen problems that great design and inspiration can take place. Some unknowns may be rev- elations about your customers and users that fundamentally change how your business interacts with them, or they may be undiscovered opportunities for progress, innovation, efficiency, and improvements to your company’s bottom line.
—————————————————-
If you are interested in reading the whole chapter, you can download it here.
More excerpts are available here
Better yet, don’t be so darn cheap and just go buy the book here
Anthony's Blog 