I was talking to my son Dan yesterday about his latest role as a product designer and a particular problem he was trying to solve. He was explaining to me how he was pondering various solutions to a manufacturing problem where simplicity was the key criteria. It reminded me of my early days as a software developer (during the 70’s and 80’s) when we would have such small amounts of processing capability at our disposal that simplicity of solution was pretty much mandatory. Today we have terabytes available on our laptops and an almost inexhaustible supply of processing capability if we need it. But does that mean we should disregard the search for simplicity? Not in my book.
No lesser being than Einstein spoke at length on the subject of simplicity. Notable quotes include – “simplicity is the ultimate sophistication” and “everything should be made as simply as possible, but not simpler“.
If I had a dollar for every piece of complex logic/code that I have debugged, during my career, I would be a millionaire a hundred times over. We see it every day. Complexity is just as damaging to our society as built-in obsolescence. We waste far too much time, so many (finite and valuable) resources, so much money on deciphering the complex messages that inundate us every minute of every day. We don’t need hundreds of variations of mobile phones or internet offerings and the associated plans that accompany them. We didn’t have any of these when we were growing up in the 60’s and we still led fulfilling lives. Nor did we have hundreds of varieties of potato, pasta or bread – for crying out loud they’re just dressed up carbohydrates!!
I’m no philistine, but the only people who win when it comes to the proliferation (and complexity) of products is big business. As Henry Ford once said, “Any customer can have a car painted any colour he wants, so long as it’s black”.
So, what has all this got to do with software testers? A lot, from my perspective. As I said previously, software doesn’t have to be complex, we just allowed it to get that way. When I say we, I mean each and everyone of us who has in the past or still does develop software.
In the mid to late 70’s we began using structured programming techniques (like JSP) in order to better organise our code. This was a way of modularising solutions and enabling re-use. However, due to a lack of (present day) communication protocols (www etc.) we really didn’t make the most of these techniques. Therefore, bespoke software solutions proliferated and became de rigueur, while so-called “packaged solutions” were, in the main, under utilised and even mistrusted (there was no Cloud to help out then). True re-use of common modules only really took off in the 90’s; again, only when realtime communication became widely accessible.
I don’t believe it is a coincidence that the massive explosion in software development in the 1980’s, and the lack of appropriate discipline/process that accompanied it, is unrelated to the advent of the job title software tester. Of course we tested software before this, but software analysts, designers and developers performed these tasks as part of their day to day roles. I also think the headlong rush to be first to market contributed to the advent of the software tester.
Following this path of logic leads me to believe that all the things that lead to the advent of the software tester can also lead to the demise. If technology itself (or the lack thereof) was the root cause then technology can also be the solution. If we revisit the premise regarding the role of software and the underlying weaknesses in the development process we could see software testers go the way of streetlight igniters, newspaper typesetters, door-to-door insurance premium collectors and switchboard operators.
I believe that the software development industry will manage to get it’s collective act together and find a way to go back to the future (circa 1974, when I began writing software) and deliver user-friendly, predominantly bug-free software without the need of specialist testers.
In summary, complexity is a dominant root cause of software failure. If we focused more on real quality (via simplicity of solutions) and less on perceived quality (via complexity of solutions) we wouldn’t be needed for these mundane tasks in life. Instead we could focus our exceptional analytical and problem solving skills on solving some of the world’s real issues – like abject poverty and world hunger. I for one, would have rather spent my years as a software tester, focusing on solving real world challenges, than finding a bug in a memory stack.
Dateline: Melbourne, Sunday October 26, 2014