It turns out that one of the key evolutionary adaptations that sets human being apart is the ability to simulate experiences. According to psychologist Dan Gilbert, in his fascinating talk on what makes us happy, ‘it’s right up there with standing upright, language and opposable thumbs as one of the things that got our species out of the trees and into the shopping mall.’ It’s because of this experience simulator that Ben & Jerry’s don’t have a “liver & onion” ice cream flavour. And it’s not because they made some up and tried it, it’s because we can simulate the experience in our heads while sitting in our armchairs.
It also turns out that our experience simulator is flawed. It works well for some types of experiences and not so well for others. Software is notorious for being firmly in the “not so well” category as illustrated by this classic cartoon:
I’m not a psychologist but I think it’s safe to say that software is simply too complex to be adequately simulated by the brain just by using words. If you think about it a software requirements specification is just that – a simulation of the actual software to be built using words. So if it’s so inadequate as a tool to simulate how a piece of software will function, then why has it been so popular as the primary means of documenting and communicating requirements?
In my experience, one reason for the popularity of the SRS is to constrain scope or to put it more bluntly, to cover one’s behind. The team or organisation building the software has an interest in constraining scope because often attached to the scope are time and resource commitments. If at a later stage the customer wants changes, then the SRS is used as a tool to justify more resources. “Sorry, that wasn’t in the original spec, we’re going to have to charge you more /it’s going to take longer / we need more developers.”
But I think the primary reason is that software emerged from electronics engineering and so naturally electronics engineers tried to apply the the engineering principles and methods that worked so well for them. As a case in point, consider the name of the industry standard for a software requirements specification document: IEEE 830. IEEE stands for Instution of Electrical and Electronics Engineers. Wait a minute? What are electrical and electronics engineers doing defining how software should be specified? I think they should stick to defining things that are, well, about electrical and electronics engineering. Like WiFi: IEEE 802.11. But the truth about the nature of software emerged over time. Software is as much art as it is engineering. It’s as much a creative endeavour as it is a scientific one. There are aesthetics and other human factors involved just as there are when building a house, another activity that combines art and engineering.
Because software is a human invention, it isn’t bound by the laws of physics or chemistry. It is limited only by the bounds of human imagination. That makes it a field that evolves at a furious pace, constantly entering into unexplored territory and with limitless opportunities to innovate. All this makes it a very exciting area to work in but it also means that there are a lot of unknowns both in the problem and solution spaces. In other words, the customer rarely has a clear idea of what he wants (“I know what I want when I see it.”), and the business analyst or architect rarely has a clear solution.
In a recent episode of the television show Mythbusters, President Obama asked the Mythbusters Adam Savage and Jamie Hyneman to revisit (spoiler alert!) the previously busted “Archimedes’ Death Ray” myth that Archimedes constructed a death ray by reflecting sunlight onto, and thus igniting, Roman vessels. A key challenge in the revisit was to design an aiming mechanism that would allow 500 people to aim at a single point their individual rays reflected off mirrors. Adam and Jamie both tested ideas in small scale. While experimenting with his idea, Adam realised that the idea itself was not feasible. But in process of experimenting with it and “seeing it”, he had a an “Eureka moment” which led to a much more superior design, one that was eventually used in the actual full-scale experiment. ‘Failure is always an option’ is one of Adam Savage’s favourite sayings and the process of designing the aiming mechanism illustrates why. At the end of the episode, Jamie Hyneman says, ‘When we experiment, when we try things, and we fail, we start to ask why… And that’s when we learn.‘ This learning through experimenting and failing is typical in software development.
So how can you efficiently deliver what the customer wants and at the same time facilitate experimentation and learning? Through mockups, prototypes and iterative development. All these techniques cater for the inherent complexity of software, the power of visualisation and the usefulness of learning through experimenting.
Here are the various techniques I’ve discussed so far on a heatmap showing fidelity vs. ease of creation.
Mockups allow the customer to effectively simulate what the end software is going to be. Paper mockups are of course the simplest way to nut out a concept for a user interface. There are lots of software tools for creating “functioning” mockups that simulate the final work software. Some excellent ones are iRise and StetchFlow.
Prototypes take this one step further and actually include key working parts allowing the customer to play with the software and the development team to experiment with certain ideas, test them out and in the process refine the solution without a lot of investment. The key type of tool that enables prototype creation is user interface controls that provide a lot of rich functionality out of the box and are easy to use (such as those made by my company Infragistics; the added benefit of using Infragistics controls is that you get a lot of UX (user experience) expertise, knowledge and investment baked into the controls, and so your prototypes automatically have rich UX that users/customers love.) Prototypes are the sweet-spot of high fidelity and ease of creation. Using rich UI controls that will be used in actual development means that there is no disconnect between what the user sees and what is finally delivered. The gap between the problem and solution spaces is minimised with minimum effort.
Iterative development by incrementally adding functionality that is tested by the customer simultaneously conserves development efforts and satisfies customer requirements effectively. Agile project management, test-driven development and continuous integration are some aspects that in my experience are incredibly effective in facilitating this.
I’d like to thank my favourite professor at university, Pj Radcliffe for arming me with these thoughts and tools very early on in my career. Thanks Pj!
Archimedes constructed a death ray by reflecting sunlight onto, and thus igniting, Roman vessels.
Like this:
Like Loading...
Akshay Luther 