5 Tips on using Rapid Application Development (RAD)

Welcome Back! I hope you enjoy the content on this site. If you have not done so already, you may want to subscribe to my RSS feed or become a fan of this blog on Facebook. Thanks for visiting!

As consultants which I believe most of the reader of this blog are, or even if you are a developer working for a software company, time is always of the essence. We are always trying to do more in less time either because we have a tight deadline or to free time to do other things we enjoy.

A concept that is not new is RAD or (Rapid Application Development) promises to let us do just that.

In fact so many software companies have tried many approaches to tackle this problem but unfortunately as it has been said before,  there is no Silver Bullet to beat the monster. There is no one size fits all methodology that can help all ISVs.

What I have seen over the years is that software vendors come up with tools that are either too hard to learn and thus us developers have to climb a pretty steep learning curve just to try them out and see if they are viable for our work environment. I am thinking here of the (Rational Rose Suite, The DSL tools by Microsoft) and so many others. Or on the other hand, they come up with too simple and weak solutions that are OK for small scale applications but that quickly bite the dust when facing large enterprise requirements. The slap on a dataset for each query comes to mind. You can try that with a multimillion records table and see how quickly it crashes!

When we started our company our first client was a large insurance company that needed a web application used by insurance brokers to sell their  products. We had a very tight deadline, and we needed a solid and scalable application that can handle multiple  transactions per second.

Today the system is not just a web application to sell insurance  products, but a full blown insurance system that handles claims, manages billing and also integrates with the company’s accounting system.

Last year we shipped version 3.0 of the online system and haven’t had a bug report since then. So how did we do it?

1. Write a framework

Even with the tight deadline we knew we had to write a solid code base that we can reuse for other projects and also to give us the flexibility to add new modules to the application without too much fuss.

The framework includes:

• Logging interface
• Data access helpers to handle transactions, factory to instantiate you DAL services,
• Exception handling and logging
• UI base objects and custom controls.

The framework should be optimized for performance and scalability. It has to be fully unit tested. You can think of it as the heart of your application, if it stops beating ..well  your application is dead.

2. Use Code Generation Tools

Back when I was in university I had written data access code generation templates for Code Smith. That’s years before LINQ or the Entity Framework. I just couldn’t bring myself to using DataSets and DataTables when I saw the performance hit when compared to DataReaders and Custom Objects.

Without code generation every time you make a change to your database you have to rewrite the Database access code, mapped objects, services, and UI. Retest everything and hope it works.

With the generated code we only need to change the services and the UI so that’s your work cut in half already.

3. Don’t reinvent the wheel for each project

Yeah I know that new tool or framework is so cool that you have to use it in  your next project. But your customer only sees 3 things in your software:

• Does it work?
• Does it address the business requirements?
• Did you ship on time?

Which framework, or technology you used is the last thing he/she will care about. So stick to what you know. I am not saying you can’t learn new techniques or explore new frameworks, but do that on side projects and don’t use it in your projects until you can answer this questions with confidence: What are the chances I blow this project if I use (insert your new framework here). And your answer is none because I used it on X, Y and Z projects and I master it.

You should also have a viable business argument why you would want to switch to this new framework. Either because it’s going to cut our development time in half, or it offers a better user experience for the client etc…

4. Simple is Always Better

Remember your main goal is to ship a working version of your software while including the most feature you can on time. This doesn’t go along so well with trying to come up with the most clever solution. For example If your application needs to get a CSV file from a webservice and parse it to include those records in the database. You can write that in a few hours. You don’t have to put a BizTalk server to orchestrate all that for you.  you get my drift? Most of the time the simplest solution is the most elegant one and the safest.

5. Modularity

I try to always  break our applications in small modules. Why?

• We can reuse those components in different project
• As customer requirements change we have very loosely coupled modules that we can just replace without having to refactor all the code.
• Give ownership of each module to a team member and thus speed development time.
• It’s easier to unit test each module.

I am sure I left a few things out so do share your ideas in the comments please.

Looking for a great book on .Net? Pro C# 2010 and the .NET 4.0 Platform, Fifth Edition

Hope this helps,

Hatim