Presenting the Art of Development

I recently gave a presentation on the Art of Development which drew on some of the ideas from this blog as well as adding some new thoughts on later chapters. It is a work in progress, later iterations will hopefully make it flow better and remove some of the unintended innuendos, but if already references some classic video games, some classic 80's movies and Bruce Lee. Enjoy...

The Bruce Lee gif is really cool but it won't work in Slide Rocket, so here he is in all his motionless glory:

A Man With A Plan

This painting of Sun Tzu has been slightly edited...

"If you fail to plan then you plan to fail" goes the old adage, and so, not unexpectedly the Art of War starts with a chapter on planning. Sun Tzu makes very clear however, that a good plan, perfectly executed, is no guarantee of victory, a fact that lies at the heart of the Agile philosophy.

"According as circumstances are favourable, one should modify ones plans" 

is how The General puts it.

Sun Tzu was a practical soldier, in the same way that Agile is a practical way of developing. He has no time for too much "bookish theoric" and cautions us not to pin our faith in abstract principles. This may seem to be an odd tack for him to take at the beginning of a big book, but it’s an important point that applies equally here and now: Anything we say here will be guidelines, not rules.

An important rule of thumb for Agile development is that you should do what delivers quality working code quickly.

So if something works for you, don’t panic just because you haven't seen it in a book, or heard it on a Scrum Master course, just get on and do it.

..but this photo of Paris Hilton is apparently real.

In our analogy between warfare and development, the enemy represents the problem that the developer is trying to solve, while victory is a successful go live, satisfied clients or working software. One of the commentators on the Art of War, Chang Yu, agrees with Sun Tzu on the importance of adaptability in attaining the #win.

"While the main laws of strategy can be stated clearly enough for the benefit of all and sundry you must be guided by the actions of the enemy in attempting to secure a favourable position in actual warfare"

No-one will read it. Seriously.

In our development terms this means: do what it takes to solve the problem at hand, don’t just follow a process blindly. Plans are important but not infallible and you must be prepared to change them, because the enemy will undoubtedly do something unexpected. This may seem fairly obvious but the tendency in development, and something viewed as a necessity on waterfall projects, is to produce in reams of documentation at the start of the project. These are essential detailed plans and given our lack of knowledge about the actual problem, our enemy, at this stage, in our team we call this process “documenting your ignorance”.

A Wellington Boot

The coolest story to illustrate this point comes from one of our own, rubber footwear namer extraordinaire, the Duke of Wellington. On the eve of the Battle of Waterloo, were Napoleon had his tiny Gallic behind handed to him, Wellington was visited by Lord Uxbridge, commander of the cavalry. He wanted to find out Wellington’s plans for the following day, in case, upon the Duke’s death, he found himself Commander-in-Chief and would be unable to frame new plans in the heat of battle.

The Duke, painted by Goya

After listening quietly Wellington asked, "Who will attack the first tomorrow - I or Bonaparte?"

"Bonaparte" replied Uxbridge.

“Well," continued the Duke,

"Bonaparte has not given me any idea of his projects; and as my plans will depend on his, how can you expect me to tell you what mine are?" [1]

Lord Uxbridge. With both legs.

Now this seems a little harsh on the poor Lord, my guess is that he was a bit of a bore, and Wellington just wanted to get rid of him so that he could kick back and get in the zone. However, if Uxbridge wasn't able to adapt his tactics to the problem in hand, the French Army's manoeuvres, then he wasn't well suited for the role of Commander-In-Chief. It is lucky that Wellington didn't get shot, as the fate of Europe may have then depended on the significantly less Agile leadership of Lord Uxbridge (He was literally less agile after the battle, as he unfortunately lost a leg. He did a good job before that though, leading a number of important cavalry charges and his leg went on to become a tourist attraction at Waterloo) 

So, the old adage is right, that no planning can lead to failure, but also remember that over planning and sticking too rigidly to your plans can also end badly, as Sun Tzu and Wellington have pointed out.

[1] From "Words on Wellington" by Sir W. Fraser

The first move...

I tell you, war is Hell!

William Tecumseh Sherman, from his address to the graduating class of the Michigan Military Academy

Things that have taken less time than Duke Nukem Forever's Development:
- The American War for Independence
- The United States' Civil War
- World War I
- The United States' involvement in the Vietnam War.
- World War II and the entire Manhattan Project. Yes, even the complete development of the atomic bomb took less time.

@Hodapp The List http://duke.a-13.net/

Sun Tzu wrote the Art of War around 2500 years ago but generals still proudly have this tome on their bookshelves today. Most have never actually read it, it's just there to show off, but those who do open it will find there are many lessons still relevant today.

Being a developer, I had the e-book version, which is light, practical, environmentally friendly and all that, but crucially, it's useless for showing off on your bookshelf. Therefore the only way that I was going to be able to boast about what I knew of the Tzu, was to actually read the thing.

As I did I was struck by a sense of deja vu (Deja Tzu perhaps?). Rigorous preparation but flexible plans, fast execution, cost savings, adaptability, morale boosting, chariots: this all sounded to me like good advice for developers as well as warriors. Had Sun Tzu lived today he might have been a general but more likely he'd be managing a development, specifically an Agile one. Because if Agile wasn't around when Sun Tzu started dev work then he would have invented it.

As the great philosopher Big Will Smith said:

There ain’t no problem that some other dude didn’t have 1,000 years ago.

So this blog will look at the lessons us developers can learn from Sun Tzu, to try and avoid the problems along our path to coding nirvana.