I downloaded a very simple little App the other day entitled Melbourne Pollen Count and Forecast. Not the most exciting App taking up space on my iKit, I grant you, but a welcome addition to my phalanx of mobile software, as it tells me the exact pollen count in Melbourne for the current day and predicts the likely levels (low, moderate, high or extreme) for the next few days. There’s no complex logic, just the reporting of some basic pollen data wrapped up in a simple graphical interface. There are very few moving parts and therefore very little can go wrong. It ain’t sexy, but it does it’s job and it makes those really bad hay-fever days a little more tolerable.
I am always on the lookout for simple and effective tools that will make my life more enjoyable or occasionally even more exciting!!! Simplicity is something I crave in my life. The world is an increasingly complex place and simplicity can be hard to find. It has therefore become a daily ritual of mine to seek out simple and effective ways to achieve my goals and enjoy life as much as possible. I have never been a complex person – what you see is what you get. No personal agendas, no political motives, no playing one off against another – just simple, straightforward, honest to goodness openness.
Being open and straightforward with others sounds easy (on the face of it), but it is amazing how many people seem to think that hiding stuff from their fellow humanoids is a form of sport – a game of cat and mouse if you will. Unfortunately, this issue has often spilled over into my software development world, where a business analyst or developer has been less than open or straightforward (with the provision of information) as I prepare for the task of testing their software. I have found over the years that those who are closed or guarded tend to write complex and ambiguous requirements or code. When you follow this pattern of thinking to a logical conclusion you will find open and straightforward software has far less bugs waiting in hiding than complex code.
So why do analysts and developers write complex/ambiguous requirements/code? Is it a lack of clear standards, guidelines or governance? Is it their need to express their freedom of spirit? Is it incompetence or poor training? For the sake of this article it doesn’t really matter, for the sake of the future of software development it matters enormously. If only we could guarantee clearly defined requirements and clear and understandable code we would go a long way to delivering far more software projects on time and on budget. We would also prevent unwanted rework and maintenance for years to come.
I think the answer to this problem lurks within many of the early SDLC phases – during the solution design. I see less and less time spent thinking and more and more time doing (and re-doing). When I was a young software designer and developer we had plenty of time to think about and discuss solutions. We drew lots of pictures and diagrams and made prototypes that we shared with our users. We took this approach because the software development process was less automated and more centralised (we mainly worked in the same building as everyone else we collaborated with). We took our time over design because a mistake took a long time to rectify. Nowadays people tend to move from idea to solution in the proverbial blink of an eye. I have seen so many poorly designed solutions fiddled with after the main development appears to have been completed – with the Developer continually stating that the solution is 99% complete…. Rework is boring. Rework is demoralising. Rework is costly. Rework is unnecessary – if you take the time up front to agree on function, form and fitness for purpose.
Never be afraid to quantify. Never be afraid to qualify. Never be afraid to question.
I always quantify the impact a piece of software will have (whether it works or fails). I always qualify assumptions and dependencies in order to build a better picture of how things will change once the new software is in place. I always question the user and/or customer in order to understand their expectations of the solution. It doesn’t take long and it saves a lot of time down the track.
Invariably once I go through my “3Qs” we all have a far better understanding of what is required and how it can be achieved. We also have a far better understanding of how important specific features are and how easy/difficult they will be to implement. In summary, we create an environment within which we can be open and forthright about what we want to achieve and how simply (efficiently and effectively) we can make it happen.
There is nothing complex or earth-shattering about this approach. As my dearly departed Dad would say “It’s just good old-fashioned common sense!!”
Dateline: Melbourne, Thursday November 14, 2013