Doing The Square Dance on Youtube

If you would prefer to listen to the podcast introducing the amazing square dance technique on youtube – go for it. No download and amazing bandwidth.

Also see it on my youtube channel here: http://www.youtube.com/user/NerdsCentral

Software Success Bites – 006 [Square Dance]

What Is It?

The Square Dance is a planning and decision making tool which I have developed over the last 10 years to massively improve productivity in production of software products. It is:

1. Simple
2. Fast
3. Effective
4. Equally at home in agile, program/project and SDLC based approaches

It works on because:

Product <= Program Of Work <= Set Of Projects

Release <=  Iterations & Backlog <= Epics

In both agile project/SDLC paradigms, there are entities from which release/product is created. Be these epics or projects, which ones are done decides what the result will be. The Square Dance gives structure and clarity to those decisions.

How To Do It:

First: Listen to the podcast

Second: Read the rest of this and then the posts to follow with worked examples:

Take a dance floor like these:

Full Colour Dace Floor Chart

Dance Floor Grey Scale

1. Pick what goes on the dimensions.
2. For each project/epic place it on the dance floor.
3. If it is in the top left: Just Do It / Green: Brilliant – that square dance says ‘Just Do It’.
4. If it is in the bottom right: Walk Away / Red: Do not do it – do not bother even doing any more square dances.
5. Do an number of square dances and make a balanced professional decision based on the combination or Greens and Yellows (Just Do It and Maybe).
6. Never do an epic or project which has a Walk Away/Red.

For example:

1. YYYGY is a project which is OK, but not great to do. Needs a lot of consideration.
2. GGGYG is a project which is pretty much a no brainer. Just do it.
3. GGGGR walk away.

Software Success Bites – 005 [Never Grow Up]

Kids are really productive, we just don’t notice it.

When my daughter wanted to get paint everywhere, she jolly well did it. When my son wants to spend all night messing with his graphics card drivers for that extra 1% frame rate, he just does it.

In that second example is hidden the real message of this software success bite. Messing about is ultra productive, ultra creative and often frowned upon. Yet it is the kid inside that programmer sat in the corner who is likely to make the next amazing breakthrough, disruptive technology or patent.

Adults (or at least the adult minded) do not mesa about. They do the dishes and ‘go out to work’. They trudge away but have the creativity of messing about stamped out of them. Never let process, time-sheets and other such adult minded paraphernalia extinguish messing about.

Messing about, trying stuff, being allowed to fail without even having anyone know about it these are the feed stock of great products and amazing end user experience. No 20% rule (20% of your time on personal projects) or other corporate controlled approach will ever help messing about flourish. Trusting your team, that is what works. That is what permits and nurtures messing about and that is what make amazing things happen.

P.S. I often cite the QM/MM force coupling engine I wrote in a hybrid language (I called GRACE) to join the Charmm molecular mechanics model with the GAMESS-UK quantum mechanical model as the most creative piece of code I ever wrote. It certainly contributed massively to my Ph.D. thesis. The first draft of the code was written one night when I had been drinking home made wine and was in a mood to mess about. Because I was just messing about, I guess I must have forgotten that it was supposed to be really complex to do and so I just did it. I love messing about.

Software Success Bites – 004 [Code Early Code Often]

Human learning is a complex, multi-stage process: Use this to your advantage!

Accepted wisdom might tell us ‘write it once and write it well’.  The idea being that we write a piece of code which implements a feature or algorithm and never go back to it.  If we are good enough programmers, we will should never have to revisit it.

This rubbish results in people spending far too long before they start coding and then they create software which is over engineered and excessively complex. Why? Because people learn and understand using multiple approaches and over an extended period of time.

‘Coding early‘ lets us learn and think about the code using the procedural features of our brains as well as the abstract reasoning parts. It also gives us a chance to spot those things we would never have thought of through abstract reasoning. There are always challenges which we will not and cannot not see in abstract analysis which reveal themselves in the doing of coding rather than in the thinking about it. By find these challenges early, we are in a good position to find solutions or re-estimate.

‘Code often‘ means write some code and then go away and come back to it a little later. Then go work on something else completely and return to the code some days or weeks later. By all means get it working the first time, but find an excuse to go back to it. In the intervening time a person’s brain will quietly process what it learned when the code was first written and consolidate that knowledge. When you revisit code, it will seem much more straight forward than the first time you wrote it or at the very least, you will be more able to visualize it as a whole. This more consolidated view allows developers to remove complexity from revisited code, even when they are adding new features.

P.S. The ‘code often’ effect is very clear to me in a project I am working on right now. I am enhancing a static code analyser and restructuring system in the code generator of the Micro Focus JVM COBOL compiler. I wrote this code some 6 months ago. Despite having to relearn some of the stuff I have forgotten, I have a much more complete overview of its role and structure than I did when I first wrote it. As a consequence I am currently making it much simpler whilst adding features!

Software Success Bites – 003 [Seek The Simple Explanation]

Hear hooves, think horses not zebras

I bought my wife a large monitor and external keyboard for her laptop whilst placing the machine behind the monitor. This set-up worked great for a few days until I heard her shouting ‘Alex, what has gone wrong?’. The web page she was looking at repeatedly scrolled up and down and nothing seemed to stop it. I checked for obvious signs of malware, problems with the page or the resolution of the screen interfering with scripts on the page. Finally the cased the cables behind the monitor. There was a cat asleep on the laptop.

All those other explanations made me feel really clever; I was the brainiac knight in shining armour. Those complex explanations might have made me feel good, but the simple explanation was the correct one.

In the language evolution team at Micro Focus we have a concept of ‘the cardboard programmer’. If someone is stuck another team member goes and sits next to them and has a look at the code. More often than not, the act of explaining the issue, or simply having someone else sat there, causes the explanation for the problem to become obvious to the stuck person. More often than not the explanation is simple.

Somehow, people seem to become blind to simple explanations. Avoid that blindness.