The wisdom contained within its pages are transferable to many situations, not just war. It could even be said that all life is war, in some form or other. Just because one is not engaged in conflict currently, does not mean that one is not at war. In fact, we remain in a state of war precisely so that we do not need to fight. After all, si vis pacem, para bellum. If you want peace, prepare for war.
Today, I would like to attempt what many bloggers before me have done before. I will attempt to apply The Art of War to software development. For this, I will be using the version translated by Lionel Giles. (I can read the characters that Sun Tzu originally wrote, but his grammar may as well be an entirely new language. Therefore, why reinvent the wheel?)
I will be listing ten lessons from this text, and the original and translated phrases that deliver these lessons.
1. Duration in Software Development
From Chapter 2: WAGING WAR故兵贵胜，不贵久
In war, then, let your great object be victory, not lengthy campaigns.
In war, then, let your great object be victory, not lengthy campaigns.
From Chapter 2: WAGING WAR
故兵聞拙速，未睹巧之久也；夫兵久而國利者，未之有也。
Thus, though we have heard of stupid haste in war, cleverness has never been seen associated with long delays. There is no instance of a country having benefited from prolonged warfare.
Thus, though we have heard of stupid haste in war, cleverness has never been seen associated with long delays. There is no instance of a country having benefited from prolonged warfare.
A software project costs more the longer it takes to arrive at completion. The cost is not merely financial; waning interest, attention span of participants and evolving situations are all costs. You want the software to still be relevant and useful by the time it is completed.
 |
| Waiting. |
This is why we now have short sprints in Agile methodology as opposed to what used to be a longer Software Development Life Cycle. The process is shorter and more iterative. It keeps the minds of those involved, active where the project is concerned. Long delays disrupt momentum.
Software objectives need to be more immediate than long-term. Developers can see the payoff of their efforts and this provides better visibility as to how the software project is taking shape. This is vastly superior to a long and drawn-out Requirements Gathering phase. One could argue that it is better to do it once and do it right; however, the definition of "right" may change drastically after a long delay. It is better to ship an incomplete but useful product and make amendments later, than potentially be forever stuck in development hell.
2. The Principle of Good Enough
From Chapter 3: ATTACK BY STRATEGEM知可以战与不可以战者胜
He will win who knows when to fight and when not to fight.
He will win who knows when to fight and when not to fight.
From Chapter 3: ATTACK BY STRATEGEM
不战而屈人之兵，善之善者也。
Supreme excellence consists in breaking the enemy's spirit without fighting.
Supreme excellence consists in breaking the enemy's spirit without fighting.
Professionally, code requires a purpose. We should not code for the sake of coding.
Professionally, best practices require a purpose. We should not follow best practices simply for the sake of following them.
 |
| Sometimes you have to fight; other times you have to chill. |
Sometimes, the best way to be a software developer is not to think like a software developer. Not every cause needs to be pursued. Not every database table needs to be fully normalized. Not everything requires a high-tech, automated solution.
Know when to code, and when not to code. Know when enough, is enough.
3. The CTO, Team Lead or Project Manager
From Chapter 3: ATTACK BY STRATEGEM夫将者，国之辅也。辅周则国必强，辅隙则国必弱。
Now the general is the bulwark of the State; if the bulwark is complete at all points; the State will be strong; if the bulwark is weak, the State will be weak.
Now the general is the bulwark of the State; if the bulwark is complete at all points; the State will be strong; if the bulwark is weak, the State will be weak.
This lesson is obvious. Software projects do not fail because of inferior technology, or inferior programmers. They fail due to poor leadership. That's not to say that inferior programmers cannot be blamed; but pushing the blame on inferior workmanship is, in itself, poor leadership.
 |
| Understand authority. |
Thus, whomever is placed in charge must not only be competent, they must understand authority.
If you are in a position of authority, it's always your fault. That is the price of leadership. Anyone who fails to understand that, has no business being in his or her position.
4. Business goals over software goals
From Chapter 12: ATTACK BY FIRE主不可以怒而兴师，将不可以愠而致战。合于利而动，不合于利而止。怒可以复喜，愠可以复悦，亡国不可以复存，死者不可以复生。故明君慎之，良将警之。此安国全军之道也。
No ruler should put troops into the field merely to gratify his own spleen; no general should fight a battle simply out of pique. If it is to your advantage, make a forward move; if not, stay where you are. Anger may in time change to gladness; vexation may be succeeded by content. But a kingdom that has once been destroyed can never come again into being; nor can the dead ever be brought back to life. Hence the enlightened ruler is heedful, and the good general full of caution. This is the way to keep a country at peace and an army intact.
No ruler should put troops into the field merely to gratify his own spleen; no general should fight a battle simply out of pique. If it is to your advantage, make a forward move; if not, stay where you are. Anger may in time change to gladness; vexation may be succeeded by content. But a kingdom that has once been destroyed can never come again into being; nor can the dead ever be brought back to life. Hence the enlightened ruler is heedful, and the good general full of caution. This is the way to keep a country at peace and an army intact.
Developers tend towards writing software. That is, after all, our bread and butter. However, sometimes we focus too much on writing good code, when our goal should be to meet business objectives. Time spent on unproductive pursuits is time that can never be retrieved.
 |
| Once broken... |
It is good to obey best practices when coding. No developer should deliberately write bad code if the situation does not call for it. But we should never let our desire to write clean, beautiful well-organized code to override the need to add value. Remember that as software developers, our job isn't to create art. If ugly code will get to the point faster, sometimes, we have to code ugly. The goals of the business trump everything else.
Code is just code. Without the business, there is no code. Software developers are not central to the business development. Our goals cannot be prioritized over business goals. We need to get over ourselves in order to contribute effectively.
5. Shut up and code
From Chapter 4: TACTICAL DISPOSITIONS古之所谓善战者，胜于易胜者也。故善战之胜也，无智名，无勇功
What the ancients called a clever fighter is one who not only wins, but excels at winning with ease. Hence his victories bring him neither reputation for wisdom nor credit for courage.
What the ancients called a clever fighter is one who not only wins, but excels at winning with ease. Hence his victories bring him neither reputation for wisdom nor credit for courage.
From Chapter 10: TERRAIN
故进不求名，退不避罪，惟人是保，而利合于主，国之宝也。
He who advances without seeking fame, Who retreats without escaping blame, He whose one aim is to protect his people and serve his lord, The man is a jewel of the Realm.
He who advances without seeking fame, Who retreats without escaping blame, He whose one aim is to protect his people and serve his lord, The man is a jewel of the Realm.
One of the greatest downfalls of the software developer is ego.
A developer who constantly tries to claim credit for work, who does not take responsibility for failure, is a detriment to the team. A developer who is obsessed with appearing competent should perhaps be more concerned with being competent.
 |
| Fly under the radar. |
When you can make your job look easy, when you can make people think that any idiot could do your job, that is mark of a true master of his craft. Developers need to stop tooting their own horns. They need to stop talking about how complicated their jobs are and how only trained professionals can do it. Just shut up and code.
6. Programming elements
From Chapter 5: ENERGY声不过五，五声之变，不可胜听也。色不过五，五色之变，不可胜观也。味不过五，五味之变，不可胜尝也。
There are not more than five musical notes, yet the combinations of these five give rise to more melodies than can ever be heard. There are not more than five primary colors (blue, yellow, red, white and black) yet in combination they produce more hues than can ever be seen. There are not more than five cardinal tastes (sour, acrid, salt, sweet, bitter), yet combinations of them yield more flavors than can ever be tasted.
There are not more than five musical notes, yet the combinations of these five give rise to more melodies than can ever be heard. There are not more than five primary colors (blue, yellow, red, white and black) yet in combination they produce more hues than can ever be seen. There are not more than five cardinal tastes (sour, acrid, salt, sweet, bitter), yet combinations of them yield more flavors than can ever be tasted.
What else could this remind software developers of, but programming itself?
There are only so many data types - integers, strings, floats and Booleans.
There are only so many data structures - linked lists, trees, stacks, heaps and queues.
 |
| Infinite melodies. |
There are only so many constructs. If-else blocks and Case statements. Iterative loops such as For, While and Do-while. And in the case of Ruby, Do-until.
But there are countless ways to put them all together. Infinite ways to achieve the result you want. Some are brilliant, some are merely adequate, and some are terrible. But that all also depends on the context upon which a programmer builds his or her program.
That is the marvel of programming. The building blocks are so elementary, but their combinations are so varied.
7. Divide And Conquer
From Chapter 6: WEAK POINTS AND STRONG我专为一，敌分为十，是以十攻其一也，则我众而敌寡﹔
We can form a single united body, while the enemy must split up into fractions. Hence there will be a whole pitted against separate parts of a whole, which means we will be many to the enemy's few.
We can form a single united body, while the enemy must split up into fractions. Hence there will be a whole pitted against separate parts of a whole, which means we will be many to the enemy's few.
This is a classic example of breaking down a large software problem into manageable chunks, and tackling each portion individually. When we solve a bit of the problem at a time, that is the Divide And Conquer approach.
 |
| Many to their few. |
This breaking down of larger software projects is also part of the Agile methodology.
There is also a lead-in into the strategy of first grabbing the low-hanging fruit. Once the easiest bits of the puzzle are achieved, this has the effect of making the entire project look significantly smaller and consequently, more doable.
8. Flexibility
From Chapter 6: WEAK POINTS AND STRONG故其战胜不复，而应形于无穷。夫兵形象水，水之形避高而趋下，兵之形，避实而击虚，水因地而制流，兵应敌而制胜。故兵无常势，水无常形，能因敌变化而取胜者，谓之神。
Do not repeat the tactics which have gained you one victory, but let your methods be regulated by the infinite variety of circumstances. Military tactics are like unto water; for water in it snatural 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. Water shapes its course according to the nature of the ground over which it flows; the soldier works out his victory on relation to the foe whom he is facing. Therefore, just as water retains no constant shape, so in warfare there are no constant conditions. He who can modify his tactics in relation to his opponent and thereby succeed in winning, may be called a heaven-born captain.
Do not repeat the tactics which have gained you one victory, but let your methods be regulated by the infinite variety of circumstances. Military tactics are like unto water; for water in it snatural 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. Water shapes its course according to the nature of the ground over which it flows; the soldier works out his victory on relation to the foe whom he is facing. Therefore, just as water retains no constant shape, so in warfare there are no constant conditions. He who can modify his tactics in relation to his opponent and thereby succeed in winning, may be called a heaven-born captain.
Some developers have this limitation - they manage to solve one problem with a solution and thereafter, every time they encounter any problem, they try to apply the same solution to it. They build themselves this figurative hammer, and everything begins looking like a nail.
 |
| Be flexible like water. |
Just as there are no constant conditions, there are no blanket solutions. Everything is context. The solution should reflect the context upon which the problem statement is derived. Developers should choose the right tools for the job, and tailor their approach according to the job.
Without that flexibility, we are not software developers. We are mere automatons, and doomed to failure.
9. Defensive programming
From Chapter 8: VARIATION IN TACTICS故用兵之法，无恃其不来，恃吾有以待也﹔无恃其不攻，恃吾有所不可攻也。
The art of war teaches us to rely not on the likelihood of the enemy's not coming, but on our own readiness to receive him; not on the chance of him not attacking, but rather on the fact that we have made our position unassailable.
The art of war teaches us to rely not on the likelihood of the enemy's not coming, but on our own readiness to receive him; not on the chance of him not attacking, but rather on the fact that we have made our position unassailable.
This should be the underlying principle of all cybersecurity. However, just in the context of software development, preparedness is the key. We cater for all the cases we can think of, and preemptively ward off as many undesirable scenarios as we can.
 |
| Prepare for the enemy. |
For example, we write unit tests for code, to screen out any nasty surprises that might emerge. On a smaller scale, if we have to deal with numbers, we test for negative values. And if we have to perform division of any kind, we first ensure that the divisor is not zero. When parsing data for insertion into a database, we sanitize it. When retrieving data from a database, we also sanitize it before use. Just in case.
We absolutely do not code while hoping fervently that nothing goes wrong; in fact, we assume that anything that can go wrong, will go wrong. We assume that people will attempt to intercept data, that bots will send forged requests, that even well-meaning users will make potentially catastrophic mistakes.
10. User Acceptance Testing
From Chapter 13: THE USE OF SPIES先知者，不可取于鬼神，不可象于事，不可验于度。
Now this foreknowledge cannot be elicited from spirits; it cannot be obtained inductively from experience, nor by any deductive calculation. Knowledge of the enemy's dispositions can only be obtained from other men.
Now this foreknowledge cannot be elicited from spirits; it cannot be obtained inductively from experience, nor by any deductive calculation. Knowledge of the enemy's dispositions can only be obtained from other men.
The science of user interfaces can be deeply complex. No one knows for certain how any demographic of users is going to respond to a user interface design. This is highly subjective and therefore we can only know by gathering this information from careful study of users. The users will tell you what you need to know, by the way they navigate the system to accomplish different tasks.
 |
| Some information can't be calculated. |
How easy is it for them? How quickly do they navigate the system? How many errors do they make?
These are the questions that cannot be calculated beforehand - the information, once again, has to be derived from study. From observing actual users.
Conclusion
There are so many lessons even upon rereading The Art of War for what feels like the millionth time, that limiting this listicle to only ten items, feels simplistic. Yet these are the lessons that I felt resonated most as a software developer.Also, this is all completely subjective. A different software developer may take away entirely different lessons. That, too, is the beauty of The Art of War.
Prepare for war,
T___T
T___T
No comments:
Post a Comment