Although there has been tremendous progress over the years, application development remains something of a black art. Results aren’t always quite what were expected, development costs may get out of hand, and at the end of the day, even the brightest guru may have difficulty pinpointing the problem.
Rapid Application Development (RAD) – one of the most prominent attempts at taming development challenges — has become an established piece of mainstream practice, conceptually linked to agile business approaches in general.
Session-based development styles, typical of the client-server era, have been superseded by collaborative and sessionless Web 2.0 methods that promise faster results. These techniques are often married to popular open source frameworks and development environments that offer a foundation for better results.
With RAD and related tools and techniques results can improve dramatically. But there is often a cost. All types of RAD promise the potential of faster development, better quality, and lower cost. But relying on sensible techniques like software reuse and distributed development is no guarantee of success. As the advertising disclaimers note, “actual results may vary” – and usually do – depending on the nature of the project and deliverable and the skill and maturity of the team and organization.
OK, so what?
One problem is that the iterative approach that is central to RAD (as opposed to the hierarchical, waterfall approach used more widely in the past) gets results that are almost right but never right enough. Developers may keep heading in the right direction, and adjusting course often, which can sometimes become a painful process of advance and retreat.
Then there’s the sticky problem of the GUI. Like used car salesmen, who know that if a car smells good and looks shiny, people may ignore the high miles and squeaky brakes – developers may succumb to the temptation to “give them what they want. Practitioners complain that end-users “kick the tires” by looking at the GUI. Even if they were qualified to take deeper or more analytical look at results, they probably wouldn’t find the time. What-they-see-is-what-you’ve-got-to-deliver when “progress” is judged by what can be assessed from the interface. So the GUI becomes the glass by which users and decision makers determine whether the project is half finished of half something else….
This problem can percolate through a RAD effort, coloring perceptions of delivery speed and subtly pressuring developers to “make it look good” rather than make it work well. And above all, get it done rapidly!
And that gets to a further challenge of RAD. Faster is better but not if it leads to problems down the road with added maintenance challenges or repair requirements. So, speed alone is not the answer. Unfortunately, software lifecycle costs are rarely examined closely.
Instead, RAD – viewed as agile and economical – can and should be a basis for careful and intelligent development.
When organizations adopt RAD approaches, it needs to be more than just a quick transition. The culture of the organization and the surrounding business processes need to come along for the ride. With RAD it is imperative that there is not only communication within a team and with stakeholders, but effective communication. Roles and responsibilities need to be clarified and understood. Authority and decision making should also be visible.
Above all there needs to be documentation and direction to ensure that the process of development starts on the right foot.
Too-fast RAD is a solution in search of a problem. More to the point, RAD must be made to fit with quality and design goals so that the ends really do justify the means.