Revisiting to get it right
When you’re on the stage and the curtain rises, it is easy to appreciate the value of getting it right the first time. If you’re well-prepared and on your game, you can be a star, if not, you’re a soon-forgotten nobody.
Early software development embraced the “get it right the first time” approach, following general engineering practices, but for many reasons, this approach did not always proven to be effective. There are obvious benefits to building a road right the first time, and extensive preparation is rewarded. The software development landscape is neither so well-defined nor as stable as the physical landscape upon which highways are built. Also, the cost of revising a road after it is built is likely higher than for rewriting code.
Nevertheless, it remains an intuitively attractive approach to attempt to get a job right the first time. “Measure twice, cut once” remains a popular expression. It requires a mind shift to feel comfortable embarking on a project knowing it will need to be revised, especially when there are pressing budget and timeline issues.
It helps to consider contexts in which an exploratory, iterative approach is favoured. Agile software development has something in common with the other side of the stage: appreciating the performing arts. When presented with a new play or piece of music, it is a vast unknown to the audience, just as the business problem is an unknown to the software development team. Of course, in both cases, the audience and development team will be drawing on whatever knowledge they have of the work in front of them, whether previous works by the same author, or what is known of the business or similar businesses.
On first listening, the audience can only follow the plot — every new development is seen as arising from what precedes it. The audience should not try to comprehend it all. The first time, the audience should just go along for the ride, with the goal of getting a general idea of the work. On the next experience, the audience will know the outline of the story, and can begin to appreciate some of the nuances: how are they being manipulated to expect one thing, when another thing is really happening? how are themes and resonances being developed below the surface? Shakespeare and Beethoven are not fully comprehended after many, many listens, and as author Jorge Luis Borges said, “Only rereading counts”.
With software development, we acknowledge that the business problem is difficult to understand and constantly shifting, impossible to grasp on the first pass. By the time one spends enough preliminary effort to get it right, the business has changed and the solution is wrong after all. We have found that the most effective approach, in many cases, is to get a quick overview of the problem, then lay out a simplified solution. By going through this exercise, knowing it will not be completely right, both the company and the developers gain insight from the exercise, and are in an excellent position to build on their experience.
Having functional software to explore, the company will have much incisive feedback regarding how that software does not serve their needs, as well as how it does. Through subsequent iterations, client input from direct experience is quickly applied back to the software by 2Paths. The same issues will be revisited, and based on the evolving software, the solutions gain depth and sureness. We efficiently build up a store of experience from not getting it right, in order to confidently converge on an effective solution for the business when the curtain finally does go up.
