We hear about RAD often. We want to use RAD. But what?s RAD?
On a lighter note, years ago, a colleague defined RAD as ?Requirements After Delivery.?
Your
requirements document would be pretty accurate if written after you deliver your app!
Of course, most of us come to talk about RAD as "Rapid Application Development." And
I think that is
wrong. If we develop application rapidly, chances are we would create a mess.
Why do I say that? I am looking at some really nice capabilities provided by RAD tools/IDEs.
For
instance, in Visual Studio 2005, you can very easily bind your windows form or web
page to data source.
You can populate your UI with not only the data you are interested in, you can
filter it, sort it, decide
how to present it, all without writing a single line of code.
This is good and bad. First let?s talk about the bad part. If used blindly, it will
turn developers into click
monkeys, and the application a nightmare to maintain. Imagine writing a web application
with 30 pages
or a windows application with several forms. You have tied the UI to the data base
using the wizards.
Now, a few months later you decide to modify the database schema or some data types.
What effect
does it have on your application? If you have to open each page or form and modify
it visually, what was
a breeze now becomes a burden.
Does that mean we should not use the wizards and the features that help us develop
quickly? Not at all;
I think we should certainly use these wizards and tools for RAD. But, I would like
to expand RAD as
?Rapid Application Demo.?
One of the key ways to succeed with (agile) development is to interact closely with
customers and get
their feedback. We should shorten the time between picking up the requirements and
checking the
expectations of our customers. If we can get the application working quickly and demo
it relatively fast,
we can get their feedback sooner. We should be able to try out new ideas, suggestions,
etc. very
quickly. Tools can help us a great deal to do that.
Then once we get their input and we know we have something that meets their expectations,
we need to
step back to see if the rapid app demoed is something that will help us or haunt us
as it is. We need to
consider if we have to refactor or redesign to make this easier to keep up with.
I think RAD is very important for agile development when the ?D? in it stands for
?Demo.?
