The Korean War - Mig Alley

The Korean War is a war I know relatively little about, other than it was the real setting for the TV series M*A*S*H (not as many thought, Vietnam) and also known for the famous last stand of the British Glouster's on a place now known as Glouster Hill, where it was made on the Imjin River. A British Army last stand like traditional British Army "last stands", being heroic but tragically a battle that in reality should never have been fought in the way it was. I have the Max Hastings' Korean War book on my shelf (both real and Audible) long overdue to be read. However, within the Korean War itself, the Air War was a bit of a mystery to me other than the enigmatic 10:1 kill ratio claimed in favour of the United Nations (aka the United States of America) pilots. It was also the training ground and inspiration for the Mad Major/Colonel (Boyd of the USAF in developing his air war combat theories) producing the OODA loop - which also decades later greatly influence AGILE software development!. Thomas McKelvey Cleaver's "Mig Alley" book came as a revelation to me in many ways (see below, a shot of the enigmatic F-86 Sabre USAF jet - its aerial combat versus the Mig-15 legendary): 

I can highly recommend the book as it came as a shocking myth buster to me - (spoiler alert if you read on) as it revealed recent statistical analysis of Soviet era and USAF era data shows the "10:1 claim" to be far closer to propaganda that proven fact. That is taking nothing from the USAF pilots who attained air supremacy over the North Korean (aka Soviet) pilots and Chinese PLAAF pilots. The revelation is that in the early combat Soviet pilots in 1951 started off on the better end of kill ratio [0.8 - 1.0] because they were filled with combat veterans from  WWII - both sides were learning first hand "jet combat". The USAF was by comparison trained (in jet flying) but unbloodied (in actual combat). The longer term operational mistake the Russians then made was to swap in and out whole Air Regiments at a time, whereas the USAF consciously only replaced individual pilots so there was always a combat capable cadre for new, the younger pilots to learn from. They were slowly bloodied from "wingman" status to "guns" - learning their trade in the skies above Korea. Boyd himself never shot a Mig down but flew 22 missions as "wingman". The seasoned in theatre air crews then returned stateside to teach tactics to the rookies before they went out. The clever American logic was assisted by the fact that there was only two Sabre air groups "spare" so rotating formations out of theatre was far too troublesome whereas the Soviets had plenty of air regiments - all of which were bloodied in turn, so each experiencing there own costly combat learning curve (and allowing an American ascendance). Then towards the 1952/53 period the Chinese pilots took over the bulk of combat were initially poorer in training and so had to relearn the lessons of the Soviets. A statistical ratio of 4:1 (in favour of the UN) was more likely over the whole war, but the early war was very touch and go. Boyd's first gut instinct about the Mig-15 being "theoretically" better than the F-86 may well be true [Boyd came to think better US canopy (observation) and automatic hydraulics (reaction time) were the difference, but in reality there was also combat experience of the man in the plane]. By comparison the Soviet cannon was greatly feared, the Sabres were comparatively under gunned with six fifty calibre machine guns - later Sabres experimented with cannon. The final remark across all eras is that pilots always over estimate their kills, with a lot of damaged planes limping home (although total write-offs on landing). 

For me the software development implications are stark (for Agile), never underestimate the value of experience - aka don't go for cheapest staff available no matter how great your AGILE SCRUM MASTER is or OODA your method is (or what the Accountant says - that is a dangerous false economy)! 

Footnote: I am trying not to "scratch the itch" of an Airfixclassic kit F-80 Shooting Star, some other manufacturer's F-86 or even the F-84 Thunder Streak - plus the Mig 15 (ironical that I had an Airfix Mig 15 in my hand years ago and did not buy it, could not see the reason then!). I think it is the RAAF Boomerang thing all over again!

SCRUM Books: Guide and Handbooks

Quite possibly my most favourite pair of books of all time in the world (see below, these two books make sense from a software development perspective, a project management sense and also a "life adventure sense" - but they also describe the evolution of adaptive complex systems - aka intelligent behaviour *see below, if that seems too academic or vague replace it with "it just makes stuff happen quickly without the bull!"): 

As always I listened to the Audible versions first, then my itchy fingers just had to get a paper copy (this happened in both cases) - "to flip through", as one has the want to do! 

Quote of the Day: SCRUM

“Embrace the unknown! That’s where learning lies! If you’re too afraid to learn, you will never get any better. This is the key to being successful at Scrum: embrace change.”

- Dr. Jeff Sutherland, The Power of Scrum

Please Keep Off the Grass

In the computer trade sometimes hype breaks common sense reasoning. Perhaps I too have been guilty of this. Drawn along by the Agile Manifesto I sounded out the mantra of "Move Fast and Break Things Quick". Perhaps I should also remember the simplest and most powerful of mathematical techniques - always view the validity of the inverse argument to see if it is more powerful! So from the lips of the Microsoft President:

https://www.bbc.co.uk/news/av/technology-49768347/microsoft-president-don-t-move-fast-and-break-things

Maybe we all can be "Muppets"! Hey those are social media weapons of mass destruction.

Brad Smith's book - Tools and Weapons: The Promise and the Peril of the Digital Age

Inspirational Books

I was asked to give a lecture at my old Alma Mater to some undergraduates to encourage them to consider doing an industrial placement year (rather than race through their degrees as quickly as possible - but that temptation is understandable in the current climate of student debt), to also pick up PRINCE 2 Project Management skills and learn (or rather practise) an Agile/SCRUM approach to product development. At the end of this by way of a light relief I offered them a reading list of work related books that changed the way I think. So here goes (see below - related specifically to the talk's content):

• Covey's - "Seven Habits of Highly Effective People"
• Sutherland's - "SCRUM: The Art of Doing Twice the Work in Half the Time"
• PRINCE2 Manual

This book (and the YouTube video of the lecture) is inspirational (see below, my personal battered copy):

You simply have to listen to someone has been an Astronaut and wants to teach you some lessons on perspective as in what is important and if it is important "how to sweat it like an astronaut" (see below):

This is a classic - not a light read but at the same time not that heavy given the importance of understanding "Black Swans" (see below, a key take away is that sometimes scrutinising every piece of information to the [n]th degree becomes counter productive, there is the powerful notion of "good enough"):

I cannot get away from Axelrod and "Tit-for-Tat" - it is such a powerful concept and proof that when you mix a Political Scientist with a Computer Scientist you get something novel and interesting (see below, his classic book and its lesser known follow on):

Lastly a general readers introduction to the Game Theory classic of the Prisoner's Dilemma (see below, and along the way Poundstone opens up some interesting nooks and crannies): 

There are more but these would keep me busy for a while on my desert island until a rescue ship came by!

Fibonacci, The Delphic Method, RAND and a little bit of SCRUM

Looking through some old emails I discovered this little gem, shame on me though I had not marked the source: 

"Frequently there are great debates about the use of the Fibonacci sequence for estimating user stories. Estimation is at best a flawed tool but one that is necessary for planning work.

User story estimation is based on Department of Defense research in 1948 that developed the Delphi technique. The technique was classified until the 1960’s (there are dozens of papers on the topic at rand.org). Basically, the Rand researchers wanted to avoid the pressure towards group conformity that typically led to bad estimates. So they determined that estimates had to be done in secret. Initially, the estimates would be far apart because people had different perceptions of the problem so they would have them talk about highs and lows after estimating in secret, then estimate in secret again. At Rand Worldwide you can read the original papers that demonstrate convergence.

Rand researchers then studied the effect of the numbers estimators can choose and found a linear sequence gave worse estimates than an exponentially increasing set of numbers. There are some recent mathematical arguments for this for those interested. The question then--if you want the statistically provable best estimate--is what exponentially increasing series to use. The Fibonacci is almost, but not quite exponential and has the advantage that it is the growth pattern seen in all organic systems. Why does the Fibonacci sequence repeat in nature? So people are very familiar with it and use it constantly in choosing sizes of clothes. For example, tee shirt sizes are Fibonacci. Since some developers are averse to numbers (a really strange phenomenon for those working with computers) they can use tee shirt sizes and their estimates are easily translated to numbers.

Microsoft repeated this research in recent years in an award-winning IEEE paper. As a result, Microsoft has abandoned hourly estimation on projects. See Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan (2012) *Scrum + Engineering Practices: Experiences of Three Microsoft Teams. *IEEE Best Industry Paper Award, 2011 International Symposium on Empirical Software Engineering and Measurement.

So the Agile community has converged on the Fibonacci as the sequence to use. Unfortunately, many agile teams do not use it properly and try to get everyone to agree on one Fibonacci number which gives you mathematically and experientially provable bad estimates through forced group conformity. This is the very thing the Rand researchers invented the Delphi Technique to avoid.

Over and over again, researchers have shown that hourly estimates have very high error rates. This is true even if the user is an expert. It’s the tool that’s the problem. If you want to practice based on evidence, relative size estimates simply deliver a much more accurate estimate."

Does anybody recognise it?

Update: I was being lazy .. it is from Scrum Inc .. Googled the first paragraph and it found it, that's nice pattern matching and I should have done it straight away!
https://www.scruminc.com/why-do-we-use-fibonacci-numbers-to-estimate-user-stories/