Sun Tzu wrote:
War is of vital importance to the state; hence it is a subject of inquiry which can on no account be neglected
In our modern world, software is of vital importance to your organization. If you can build software consistently and reliably you will gain a tremendous advantage over your competition. If developing software is like waging war then who is the enemy? The enemy is complexity. Complexity comes from having to make dozens of
decisions correctly for your software project to even have a chance of succeeding. For every thing that you know at the outset of the project, there will be at least ten things that you don’t know.
Complexity is compounded by having to make those decisions on a deadline, especially if that deadline is not well chosen. So when you consider launching a software project you must understand that you are looking at the tip of the iceberg. Your ability to handle uncertainty will dictate how successful you will be. Unlike a conventional war this enemy does not sleep, has no obvious weaknesses, and can not be deceived. Once you engage the enemy your success will depend on correctly estimating the magnitude of complexity and making excellent decisions.
Sources of Uncertainty
If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle. Attack by Stratagem, p. 18
Uncertainty comes from a few main sources:
- Team resources unfamiliar with the technologies to be used
- Requirements that are incomplete or inconsistent
- Technical requirements that turn out to be infeasible
- Inability to understand project dependencies
- Inability to formulate a correct and understandable plan
Unlike fighting a conventional enemy, complexity will find all your weaknesses. The only way to defeat complexity is through understanding the requirements, having well trained teams, building a solid project plan, and executing well.
Unfortunately the way most organizations develop software resembles the Charge of the Light Brigade (poem). In that battle about 400 men on horses attacked 20 battalions of infantry supported by 50 artillery pieces. Needless to say it was a slaughter.
The Art of War (online)
Several principles outlined by Sun Tzu apply to software development as well:
- Leading to advantage
- Using Spies
- Strengths and weaknesses
- Winning whole
Since the enemy is complexity we can not deceive it. Rather the problem is that we allow ourselves to be deceived by complexity. How often do you see developer’s say that they can code anything over a weekend over a case of Red Bull? People generally do not launch software projects because they want to
fail;but when only 3 out of 10 projects succeed, it shows that people have been deceived about the complexity of building software. This statistic has haunted us for 50 years. Senior management should really pause and consider if all their ducks are lined up in a row before embarking on a software project. Unfortunately senior management is still underestimating complexity and sending teams to face virtually impossible projects.
Leading to advantage
Thus it is that in war the victorious strategist seeks battle after the victory has been won, whereas he who is destined to defeat first fights and afterwards looks for victory in the midst of the fight. Tactical Dispositions, p. 15
Complexity emerges from the sources of uncertainty mentioned above. Successful organizations plan to remove known uncertainties and have a plan to handle the ones that will emerge. Getting into a project before understanding the magnitude of the uncertainty is a recipe for failure.
That the impact of your army may be like a grindstone dashed against an egg—this is effected by the science of weak points and strong Energy, p. 4
The team’s energy needs to be directed against uncertainty with appropriate force at the appropriate time. When this happens uncertainty will be minimized and the chances for success will increase. It is imperative to create a table of all risks that might affect your software project. If you aggressively minimize the probability of risks triggering you will reduce uncertainty and increase your chances of success. Software projects succeed when there is a rhythm to the attack on complexity. High intensity problem solving needs to be followed by lower intensity stability building. The team must move at a sustainable pace or risk burning out. Software teams do not succeed when they are working 10+ hours a day; they become like dull swords — unable to do anything.
Foreknowledge cannot be elicited from ghosts and spirits; it cannot be inferred from comparison of previous events, or from the calculations of the heavens, but must be obtained from people who have knowledge of the enemy’s situation. Using Spies, 5 —6
The enemy is complexity and is intangible, i.e. invisible, odorless, and untouchable. Your spies are your business analysts, architects, and project managers. Your business analysts will work with the business to define the scope of the complexity. Ask for anything you want, but commit to build all you ask! Remember that all large complex systems that work are built from small simple systems that work, so aim to build the smallest usable product initially. Asking for too much and providing insufficient resources and/or time will lead to a failed project. The architects provide checks and balances on the business analysts to make sure that the project is feasible. The architects will provide key dependency information to the project managers who make sure that a proper execution plan is created and followed. Each of these spies sees a different aspect of complexity that is not visible to other people. Unless the reports of three types is combined effectively you risk not knowing the extent of the software that you are trying to build. If you go into battle without proper intelligence you are back to the scenario of the Charge of the Light Brigade.
Strengths and weaknesses
Military tactics are like unto water; for water in its natural course runs away from high places and hastens downwards. So in war, the way is to avoid what is strong and to strike at what is weak. Weak Points and Strong, p. 29—30
Water exhibits ordered flexibility. It is ordered because it seeks to flow downhill; however, it is flexible and will go around rocks and other obstacles. A software project needs to make continual progress without getting sandbagged with obstacles. Methodologies like RUP or Agile software development can make sure that you exhibit ordered flexibility.
Winning whole in a software project means delivering the software on time and on budget without destroying the health and reputations of your team (including management). Failed projects extend their effects to every member of the team and everyone’s resume.
When you engage in actual fighting, if victory is long in coming, then men’s weapons will grow dull and their ardor will be damped. Waging War, p. 3
When organizations bite off more than they can chew they exert tremendous pressures on the team resources to work extended hours to make deadlines that are often unrealistic. In the pressure cooker you can expect key personnel to defect and put you into a worse position. How many times have you found yourself on a Death March?
Both waging war and software development are serious topics that involve important struggles. If software development is a war against ignorance, uncertainty, and complexity then many of the strategies and tactics outlined in The Art of War give us direction on how to execute a successful project.
This guide will introduce you to the world of Software Architecture!
This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.