Here is the next of the square dances. See Also:
- Software Success Bites – 008 [Risk vs Impact]
- Software Success Bites – 007 [Big Small Hard Easy]
- Software Success Bites – 006 [Square Dance]
Most people in software are painfully aware of requirements. Running projects with poor, fuzzy or missing requirements is a recipe for disaster. However, there is another dimension to producing the correct result (which is what requirements are supposed to be about). Common goals and vision are as if not more important the excellent requirements. These have to be shared; i.e. discussed and a common understanding reached.
- Shared goals and vision couple with a good but not too restrictive set of requirements is route to joy. Just Do It.
- If the drivers for the product (those asking for it or paying for it) share a very clear common vision and set of goals with the developers we might get away with no requirements. But this project might end up with arguments over if it is complete or cost overruns.
- If there are excellent requirements and no common share goals of vision, the project might succeed but is more likely to end up in litigation because the requirements will be met but the result not like the drivers wanted.
- If there are no requirements and no common goals or vision then walk away. We need to be super careful here because frequently drivers will assume the goals and vision are ‘obvious’ and ‘not worth discussing’. However, because they are coming from a completely different mind set to the developers, nothing is obvious and everything is worth discussing.
Here is the next of the square dances. See Also:
The risk considered here that of a project and/or epic not being completed. Whilst this can be a time/resource thing, here we are more considering simply ‘will it be possible’ or ‘will it work’. Some ideas simply do not pan out or even if they are completed end up being much less usable or effective than originally th0ught.
The impact considered here is ‘if we managed to do this, how big an impact on the user/business/application’.
If there is little chance of getting something to work and, even if it did, the benefits (impact) would be minimal, why bother? That is obviously a Walk Away.
If the impact of something is huge and the risk of not managing it is minimal, the it is a Just Do It.
- Adding and, or + and – operators to a plain text search function has been done before, low risk and helps a lot, big impact. Just Do It.
- Adding a natural language comprehension system based on parallelized artificial intelligence has been tried many times and no one has managed yet (to do it well). When someone does, it will be amazing. This is a maybe!
- Adding the ability to upload png’s of hand written queries to a search system is unlikely to work well because hand writing is so variable. Anyhow, there is no point because people use keyboards or virtual key boards. This is little or no impact and is very high risk. Walk away!
This was the first one I developed and I swear by it!
- Small projects go at the top
- Big at the bottom
- Easy to the right
- Hard to the left
In the example (right) the project (or epic) which I have marked with a red X is a no brainer, just do it. This is both easy and small! However, the epic (project) marked with a blue X is a walk away. It is big and hard, so not worth doing.
Installing gcc on a Linux box: Small and easy.
Creating a new C compiler on a Linux box: Big and hard.
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
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:
- 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:
- Pick what goes on the dimensions.
- For each project/epic place it on the dance floor.
- If it is in the top left: Just Do It / Green: Brilliant – that square dance says ‘Just Do It’.
- If it is in the bottom right: Walk Away / Red: Do not do it – do not bother even doing any more square dances.
- 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).
- Never do an epic or project which has a Walk Away/Red.
- YYYGY is a project which is OK, but not great to do. Needs a lot of consideration.
- GGGYG is a project which is pretty much a no brainer. Just do it.
- GGGGR walk away.
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.
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!