Monday, May 05, 2008

Rapid App Development, friend or foe

The world needs faster ways of doing things. Machines crunch numbers faster, hard disks spin faster, networks transport bits faster, the real bottleneck seems to be creating software faster. We are limited by how fast we can code. No matter how many code generation tools are available, the developer community is so obsessed with knowing every line of code that was ever written. That is our real speed bump, the human mind can process only so much information and assistive tools are a necessity to move faster.

RAD tools have always been built on the assumption that the tool is just an assistive technology to developers and generated code should be editable. That defeats the purpose of rapid application development, Its like assigning the human mind an extra task of trying to make sense of alien code and then modify it. A better approach is to generate components that can be treated as individual building blocks, and not chunks of code that needs editing. Better still the whole solution should be as easily editable and creatable.

These attempts have been made in the online world in the guise of mashables and web 2.0 content. But the real power of RAD will be when you can build solutions to everyday problems.

RAD and the software models
Software development methodologies can be categorized into pipeline or waterfall like models and evolutionary models. Today evolutionary approaches like prototype, spiral and scrum models dominate the landscape. The need to constantly adapt to changing requirements and clarify requirements on the go make the later models more attractive.

Building prototypes is a well accepted practice in evolutionary models. They help clarify requirements and sometimes validate uses cases. Many times prototypes are built to be thrown away, which makes sense in some cases, but largely building prototypes as extensible pieces that can later become a complete solution is where the most payoff lies. And it is here that RAD tools play an important role.

When customers see a well developed prototype they easily mistake it to be a working alpha or beta solution. And there is no reason why a well developed protoype should not be be ready to use. There are many advantages in building a strong usable prototype. It saves a lot of time in reimplementing the actual solution. Developers shy away from writing strong extensible prototype code because of the throw away factor, and the throw away factor comes in because of the non-extensibility of code over a few iterations. Its like a chicken or egg problem.

By using components from a RAD framework, developers can be assured that the code is tested, validated and ready for use on the first day or click, and the solution can definetely be extended over iterations by adding or removing components. The big catch is that the component palette should be complete and ready to use.

Power of iteration
The big advantage of using component frameworks is that you get to test a solution as you build it, which is a dream come true for many developers. It is obvious that code cannot be completely validated until it is fully functional. But with the components approach, each block is fully functional by itself making it easy to test drive the solution as it is built. Imagine adding a forms component, and then immediately adding a few records, or adding a reports component and verifying what it generates. You could add and try out components on the fly and end up with a complete and fully validated solution within a few iterations.

Redefining productivity
In the RAD world, Productivity can no longer be measured in lines of code, it would be more like features per hour or applications per week. Even RAD sounds out of place, The right term would be Rapid Component Integration.


From simplicity comes creativity
With that kind of simple tools to build solutions, we can start putting together custom solutions to every little problem we come across. The day is not far when packaged software would be considered an alternative to DIY solutions and not the other way round.

0 Comments:

Post a Comment

<< Home