If you’re in software, you’ve probably heard of the divide and conquer approach. It’s about breaking a problem into smaller chunks (divide) and tackling them directly when they become manageable (conquer).
Interestingly, this concept stems from an ancient political tactic (its Latin root is divide et impera) suggesting that sowing discord among your people helps you stay in control.
Leaders like Julius Caesar and Napoleon used this strategy effectively. Caesar divided the Gauls to conquer them, while Napoleon, a master strategist, would split enemy forces, disrupt their communication, and then attack when they were weakest.
The Art Of War: Ancient Wisdom for Modern Development
However, divide and conquer isn’t the only political strategy relevant to software development. While coding and combat seem worlds apart, both developers and generals lead teams, collaborate, strategize, and manage resources.
The Art of War is an ancient Chinese military text written around the 5th century BC. Attributed to Sun Tzu, a brilliant strategist, its principles have influenced both Eastern and Western thought.
Even today, military institutions worldwide study this book. Divided into 13 chapters, each focuses on a different aspect of warfare.
But Sun Tzu’s wisdom isn’t limited to war. It applies to politics, business, sports, and surprisingly, software development. You might even be using some of his principles unknowingly.
Below are a few tactics from The Art of War that resonate with the software world.
Time: The Essence of Every Project
Chapter II, paragraph 2
Prolonged battles dull weapons and dampen spirits.
In software, this translates to the impact of lengthy development cycles on morale.
Working on the same project for months with no clear end in sight can frustrate developers and decrease productivity.
Motivation fuels software development, which is an intellectual pursuit. Seeing no tangible results for your effort can be incredibly demotivating.
Agile methodologies emphasize breaking down the development process into smaller, achievable goals, providing a sense of accomplishment and progress.
Chapter II, paragraph 18
In war, aim for swift victory, not prolonged campaigns.
This has two interpretations for software development:
First, it echoes the UNIX philosophy: Do one thing well. Focus on the software’s core purpose, its primary feature, or the main problem it solves. This is crucial for custom software designed for specific needs.
Resist adding unnecessary features just because you can. Applications overloaded with rarely used functionalities are often called bloatware.
Second, it aligns with the lean software principle: Deliver fast.
Delivering functional software quickly allows for quicker feedback, enabling faster incorporation of changes. This is fundamental to agile development.
Delivering non-functional software means missed feedback opportunities, making the next development phase harder, sometimes impossible.
Leadership: The Cornerstone of Success
Chapter III, paragraph 11
The general safeguards the state; a strong general, a strong state; a weak general, a weak state.
This emphasizes the project manager’s role: a project’s success depends on the strength of everyone, and the manager is the cornerstone. Responsibility starts from the top.
While developers often work independently, they need strong leadership. Project managers ensure everyone stays on track, communication is effective, conflicts are resolved, and priorities are set. Never underestimate their role or their responsibility if things go wrong. Just imagine a general whose unit fails on the battlefield.
Even with a few weak links in the developer chain, a team can still deliver great software. But a weak project manager makes success unlikely, no matter how talented the developers are.
Chapter VI, paragraph 28
Avoid repeating victorious tactics; adapt to the ever-changing circumstances.
It’s tempting to reuse technologies from past successes (same language, libraries, servers, etc.). However, unless the new project’s requirements are identical, this can be detrimental.
In programming, there’s no magic bullet. No single technology stack solves every problem; each has strengths and weaknesses.
While learning a new language or API can be initially demanding, it often leads to better software quality and developer growth in the long run.
Chapter XIII, paragraph 27
Wise rulers and generals use their best minds for espionage, achieving great results. Spies are crucial in war, for they guide the army’s movements.
This highlights the importance of monitoring tools and logging libraries during maintenance.
Software development doesn’t end with a stable release. It’s an ongoing evolution involving bug fixes, new features, and performance enhancements. Maintenance is crucial.
What better way to understand what needs changing than having “spies” monitor the software in its natural environment? They can track feature usage, common errors, and slow operations.
Error reports, logs, and usage data are vital for detecting bugs, bottlenecks, and other issues often difficult to replicate in controlled settings. This information then feeds back into the development cycle.
Teamwork & Motivation: The Heart of the Matter
Chapter X, paragraph 24
Advancing without seeking fame, retreating without fearing blame, protecting the people, serving the leader—such a one is a treasure.
This is the ancient Chinese version of teamwork over personal glory.
Software development thrives on collaboration. A good developer doesn’t just fix bugs or write code quickly; a good developer elevates the entire team.
Taking all the credit, deflecting blame, or calling yourself a “code ninja” might impress some, but it ultimately harms the team.
Chapter VII, paragraph 21
Think before you act.
This emphasizes the importance of team discussions, a cornerstone of agile methodologies.
Discuss any significant changes before implementation. Whether you’re the team lead or the most experienced, involve the team.
Other developers might offer valuable insights into different parts of the software, potentially speeding up implementation.
Chapter X, paragraph 25
Treat your soldiers like your children, and they will follow you into the deepest valleys; cherish them as your own, and they will stand by you till death.
This emphasizes the often-overlooked principle of motivation. Motivated developers produce better code, work faster, make fewer mistakes, and are more willing to go the extra mile.
Managers create motivation by taking a genuine interest in their team, listening to them, respecting their work-life balance, fostering a positive work environment, and supporting their career growth.
Don’t confuse motivation with money. Recent studies show that while money attracts and retains talent, it doesn’t guarantee job satisfaction. Raises and promotions shouldn’t be the only motivational tools.
Thinking Outside the Code
Chapter V, paragraph 7, 8 and 9
Five musical notes create countless melodies.
Five primary colors create infinite hues.
Five cardinal tastes create endless flavors.
The beauty of programming lies in its boundless possibilities; you can create almost anything (except, of course, the impossible).
Mobile apps, websites, games, desktop applications—all within reach for a skilled programmer.
Chapter III, paragraph 1
The greatest victory is to conquer without destroying; capturing an army is better than annihilating it, just as capturing a regiment is better than destroying it.
Large codebases often contain poorly written or outdated modules. While it’s tempting to delete (or “destroy”) such code, it’s not always the best course of action:
Legacy code isn’t always bad. It might be well-written code from a time when different practices prevailed. It might be old, but it still works.
You risk wasting time “fixing” functional code instead of focusing on critical areas.
Unless you’re absolutely sure, replacing working code risks introducing new bugs.
This doesn’t mean “If it ain’t broke, don’t fix it” is a good strategy. Every project has priorities, goals, and deadlines. If you find improvable code, discuss it with your team or project manager to determine when optimization makes sense.
Chapter VIII, paragraph 3
Some roads should not be taken, some armies not attacked, some cities not besieged, some positions not contested, some commands not obeyed.
This can be interpreted as a warning against anti-patterns.
While anti-patterns might offer quick solutions, they often become detrimental in the long run. No matter how tempting, how much time they save, or how many bugs they seem to fix, avoid them.
It’s tempting to use an anti-pattern for an urgent task, promising to fix it later. But remember Murphy’s Law: All quick fixes become permanent changes.
Conclusion
Developing software and leading armies or nations are different, but they all require problem-solving, teamwork, leadership, efficiency, and sustainable solutions.
The Art of War isn’t the only source of wisdom applicable to software development. Niccolò Machiavelli’s The Prince is another example.
Here are some quotes from Machiavelli relevant even today. Can you find their parallels in the world of software development?
- The lion cannot protect himself from traps, and the fox cannot defend himself from wolves. One must therefore be a fox to recognize traps, and a lion to frighten wolves.
- Never attempt to win by force what can be won by deception.
- Never was anything great achieved without danger.
- Whosoever desires constant success must change his conduct with the times.
- Men in general judge more from appearances than from reality. All men have eyes, but few have the gift of penetration.
- He who wishes to be obeyed must know how to command.
- Wisdom consists of knowing how to distinguish the nature of trouble, and in choosing the lesser evil.
- There is no avoiding war; it can only be postponed to the advantage of your enemy.
- Nature creates few men brave; industry and training makes many.