Mr. Mahal has worked his way through all aspects of software development. He started as a software engineer and learned how to design and architect software systems in different industries. He has been a director of engineering, product management, and professional services; mid-career he worked for a company dedicated to training engineers in collecting requirements and understanding OO and conducted research into why software projects fail; and before starting Accelerated Development he rescued a technology startup in Vancouver as their COO. Accelerated Development is dedicated to the production of high quality software through implementing light weight engineering practices for all size organizations up to Fortune 500. Dalip is a DZone MVB and is not an employee of DZone and has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

The Art of War: How it Applies to Software

06.17.2012
| 1144 views |
  • submit to reddit

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? 

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.

                                                                 Laying Plans, p. 1

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:

  • Deception
  • Leading to advantage
  • Energy
  • Using Spies
  • Strengths and weaknesses
  • Winning whole

Deception

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.

Energy

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.

Using Spies

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 what 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

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 areoften 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?

Conclusion

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.

In a subsequent article we will show that Agile software development isa project methodology that meets all the criteria of Sun Tzu.

References
Published at DZone with permission of Dalip Mahal, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)