Ten Lessons From The Art Of War Applied To Software Development

Few written works are as universally well-known as The Art of War by Sun Tzu. This military treatise has been repeatedly translated, referenced, read and reread through the millennia that have followed since its creation.

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.

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.

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.

From Chapter 3: ATTACK BY STRATEGEM

不战而屈人之兵，善之善者也。

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Discrete And Continuous Data Defined

When dealing with data, one of the things we should take note of is the type of the data. Is it numeric or string? Boolean? Date, even?

If the data is numeric, we would then have to consider whether the data in a dataset is discrete or continuous. It is only after such a classification, that an analyst would be able to decide on the best way to visualize this data.

Discrete data

Data is said to be discrete if there the data points are distinct and separate from other data points in the dataset. There are restrictions to the value that these data points can have. Usually, these restrictions take the form of the value being a whole number and not a fraction.

Take for example the number of silver cars in a showroom, the number of people attending a Rolling Stones concert, or the number of eggs sold in a supermart on weekends. You can't have a fraction of a car, or a person. And definitely not half an egg, at least, in raw form.

Number of silver cars in
a showroom.

Think of discrete values as countable data. Numbers that have to be counted.

Discrete data is easy to visualize. Bar charts, line charts, etc, all these handle discrete data quite readily.

Continuous data

Data is said to be continuous if the values of data points can take on any value within a certain range. This usually means that the data can be from an infinitely precise measurement.

Take for example the temperatures taken on a certain day of the week, the speed of the cars on the road, or the heights of different buildings on a street. The values are not restricted to whole numbers - a temperature can be a value like 30.01657 degrees Celcius, for instance. Depending on how precise you wish to be, the figure could go on even longer.

Measurable values.

Think of continuous data as measurable values. Values that have to be measured by an instrument such as a thermometer or gauge.

Continuous data is best represented by line charts. If grouped into discrete categories of ranges, they can also be represented much the same as discrete data.

What about monetary figures, such as profits?

One might be tempted to think of this as a continuous measure, because profits is a measure of money, which uses decimals. For example, the figure 1,400,450.25. However, the decimals are actually representations of cents. So in essence, the figure means 140,045,025 cents. It's not a fraction, exactly.

Money can be counted.

Also, remember, discrete figures are counted. Money is counted. Therefore, monetary figures are discrete.

In a nutshell

The difference between discrete and continuous data is straightforward in most cases. It is usually when decimal places are involved, where confusion sets in.

See you lata, alli-data!
T___T

When Zuckerberg Met(a) Facebook

What in the world just happened? Facebook is changing names!

Last month, in what feels like it should have been more of an earthshaking moment, Mark Zuckerberg announced in a series of public conferences, that Facebook would now be named Meta Platforms, Inc. It was not to be just a cosmetic name change. The change went deeper than just a name and logo.

The existing Social Media and communications platforms - Facebook, Instagram and WhatsApp - will take up half of Meta. The other half will be dedicated to the construction of a metaverse. Just what in the heck is a "metaverse", you may ask? Tt is a virtual world where, if Zuckerberg achieves his vision, users can interact with an augmented or virtual reality environment in real-time. Hence, "Meta".

A metaverse!

Cynically, of course, one could see this as a matter of branding for Zuckerberg, nothing more. If he's to be believed, this was the direction they were heading all along and the name change is just meant to reflect that. The problem, according to him, is that Facebook is currently seen a a Social Media company. (No shit, really?!)

This move might prove to be worthwhile for Zuckerberg. After all, the abovementioned platforms all depend on mobile technology for propagation. That makes Facebook, as a company, vulnerable to the rules imposed by Google and Apple. And we all know Facebook has faced strong opposition to both entities in the recent past.

But what if Zuckerberg were able to pivot Facebook to a new kind of platform, one which wasn't dominated by Google and Apple? I'm not even gonna front - the possibilities are, to say the least, intriguing.

The Meta-conclusion

Honestly, I can't see the name change sticking. We're talking about over ten years' worth of inertia at this point. And let's be real here - "Meta" isn't exactly catchy or original. And the less said about the sheer lameness of the logo, the better. Seriously, were they maybe hoping to be as unimpressive as possible?

What's more pertinent, however, is the nature of Facebook's - ahem, excuse me, Meta's - business model. If they are truly pivoting to virtual reality, that is a huge deal if they manage to pull it off. Will they? The technology is there, but how much of it could truly permeate a market where internet strength can be spotty at best? Your guess is as good as mine.

It's been real,
T___T

Thoughts On The Ongoing Millennial-Boomer War (Part 2/2)

OK! We've seen the millenial point of view, agreed with some of it and ripped into the rest. Boomers are going under the microscope next.

What Boomers say about Millennials

The younger generations are soft and spoilt. They're irresponsible, whiny snowflakes. They have no idea how hard things were back in the day. They're idealistic and self-righteous, and think that they can change the world by undoing the past. But their arrogance, combined with naivete, is their undoing. The world is what it is. What makes them think they can change it? They have no consistency. They're so entitled and don't believe in the values of hard work and loyalty, changing jobs on a whim. Young people just don't know what they want in life.

Why Boomers are right

Some things are not era-specific. Some principles apply regardless of the times we are currently living in. And it's these principles that make Boomers valuable, if they have been consistently applying them to their lives. Millennials would do well not to dismiss Boomers out of hand just because their words and experiences come from a different era. Not only is that lazy, it is foolhardy.

The Boomers also have a point about this overdoing of Woke Culture that seems to be a hallmark of this generation. It's one thing to advocate for awareness of Climate Change, Minority Rights, Social Justice, and so on. But digging through someone's tweets from ten years ago, and holding them accountable for those? Going way back into ancient history to attack long-dead personalities? That is so banal. Shouldn't the leaders of the future be more concerned with, y'know, the future?

Plant a seed of change,
not a tree.

Change is a natural aspect of our reality. Change occurs regardless of anyone's attempts to stop it. It also occurs at its own speed regardless of attempts to speed it up. So trying to effect change for the sake of change itself, is unproductive. If the younger generation pushes for change and encounters pushback, maybe it's time to consider that this isn't the time for that particular change. The overemphasis on things like Affirmative Action and erasure of potentially offensive terms in tech is what I call "trying too hard", and it's counter-productive.

Get the seeds of change right, and change will happen. Millennials need to stop trying to produce an entire tree overnight. There's a process to this shit!

Why Boomers are wrong

No matter what you may think of Millennials, remember that they are now the dominant majority demographic where the workforce is concerned. They will, by default, be the ones charting the course for the future. Who else is gonna do it? You, Boomers? Face it; your time was over ten years back. Whatever mistakes Millennials may or may not make, they are the ones who are going to have to live with it. Statistically, you are going to be long gone by then. You have no skin in the game. So stop trying to exercise influence over a world which you won't have to be responsible for.

You probably think Millennials change their minds way too often, as compared to the days where you stuck to one course your entire lives and never deviated? It's frightening that this lack of flexibility is actually considered a virtue.

People change their minds more often now because they can. It's called having options. Let's be real - if you had that many options back in the day, would you be doing what you're doing now? Not having options is not the same as being steadfast. The internet has opened up a multitude of options. There are multiple paths to success, and as the conditions for success change, so too, must the course you are on.

Agility is a mindset that is encouraged in the workforce today. The Agile Methodology is a concept bred in software and now business - that one must constantly make adjustments to work plans based on ever-evolving conditions. If people with static mindsets were in charge, we would not be seeing the great leaps in progress that we're seeing today.

Are Millennials really lazy?

As for knowing the value of hard work, quit the bullshit myth that Milllennials are lazy. They are just as capable of working hard... except that unlike you, apparently, they want their hard work to mean something. Hard work for the sake of hard work is even dumber than change for the sake of change. In your day, hard work was the only value you brought to the table. But in this day and age, any idiot can be hardworking. So if you want to get ahead, you better have a hell lot more to offer than your sweat, blood and tears.

And finally...

"In my day..." doesn't help your case at all. You're trying to make a point as to why things should be done a certain way. Even if people were interested in a history lesson, a history lesson from your personal point of view is pretty fucking useless except for entertainment purposes.

Also, stop with the unsolicited advice. If your advice was so valuable, people would be paying you to talk. Are people paying you to talk? No? Well, take that as a sign from the universe.

The war continues!

Nothing I've said here is going to change anything. People are going to think what they think and do what they do, even if it is absolutely stupid. It's a very human thing.

Did I mention I'm taking no sides here? Millennials and Boomers both suck. Seriously. Honestly, what kind of idiot thinks that simply being born in a particular era makes them special?

The world continues to spin no matter how important you think your perspectives are. Millennials, one day you will be those Boomers you love to shit on. Boomers, one day you will be corpses and distant memories. Get over yourselves, guys.

Tale as old as time!
T___T

Thoughts On The Ongoing Millennial-Boomer War (Part 1/2)

There's been a low-key war between Millennials and Baby Boomers (or "Boomers", for short) that has been simmering for years, and while other tiny petty wars have broken out, this particular one shows no signs of going away. Every other day, I see people dismissing the opinions of others citing the disparity of age as a reason. Both parties are equally guilty of this.

As a member of Generation Y, born in 1997, I fall fairly in the middle of these two sides and I've had to suffer douchey behavior eccentricities from both camps. And this is what I think. I think both sides are right... and also wrong.

This is what I have to say about it, and unsurprisingly, much of it will be from a software point of view.

What Millennials say about Boomers

They're always going on about how things should be, and are stubbornly against accepting new ideas. They refuse to accept that some things that were OK in the past are not OK now, and they don't understand the value of social justice. They think we're naive and idealistic, but we actually know more shit because we have the internet now. We keep ourselves informed; they go around spreading conspiracy theories. They're out of touch and just don't get it. They're preachy and think they know better simply because they're older. Simply put, they resist change and are afraid of it.

Why Millennials are right

Change is inevitable. Change takes place all the time. Tradition has its own undeniable charm, but it shouldn't be a ball and chain. Tradition has its place and more importantly, tradition must know its place.

What would the world be like if people insisted on doing things the way they've always been done? For one, the software industry, as we know it now, would not have made the advances it has made today or made such great leaps. Software development, by itself, is something that defies all tradition. It has automated jobs that once were thought to be the sole province of lifelong practitioners. Software development is the quintessential example of constant evolution.

The assertion that older people know better is laughable at best. You do not know better simply because you've experienced more. What you've experienced matters. Relevance of experience, rather than quantity, matters. You do not ask an experienced farmer to do the work of a chef, or vice versa. Growing corn and cooking corn are two entirely different skillsets.

You don't ask a chef
to grow corn.

If I were to apply for a job in Java despite having no professional experience in Java at all, and tried to use my decade of experience in JavaScript as a bargaining chip, I would be laughed out of the interview room. And I would deserve it.

Same with Boomers. Boomers need to stop using quantity of experience as a flex. If they must flex, they need to use both relevance and quantity. Unfortunately, relevance of their experience can be in short supply precisely because the world has changed a lot since, and will keep changing.

Why Millennials are wrong

On the other hand, while it's true that the younger generation is more tech savvy and thus knows more about gathering information online, the same logic - relevance over quantity - can and should be applied. In an age where online misinformation reigns supreme and there is no minimum I.Q requirement to post content, more information does not mean better. 10,000,000 or 100 times 0 is still 0.

And before people start yapping about how authentic their information is, stop right there. Everyone thinks their info is authentic, unbiased and the objective source of truth. You're not special in that regard.

And sure... Boomers can be preachy AF. They like to do this big song and dance about how things used to be, and how everything has gone to shit now. The thing is, Millennials don't exactly have a leg to stand on where preachiness is concerned. Climate Change, anyone? Gender Equality? Gay Rights? Oh yeah, you probably think you have a free pass to pontificate about how people should live their lives because your cause is more noble, right?

Get off your soapbox.
Nobody's impressed.

Please, fuck off that particular high horse. Preaching is preaching.

And finally...

"OK Boomer" sounds cool, you think? A nice pithy comeback to display your contempt without needing to resort to a lot of words, or worse, having to formulate a thoughtful response?

No, it's lazy. It means a whole lot of nothing. And overuse makes you look like a petulant child. It reinforces the harmful stereotype that young people have nothing but empty sarcasm as a response. You should be better than this. Either don't respond, or say something intelligent.

Next

Let's examine those goddamn Boomers.