RAD 2.0 - the chaos theory

The Information Technology sector has over the years developed, tested and implemented new ways and processes to developing IT systems. To name a few and to bring this into perspective, we have the traditional SDLC, the JAD (Joint Application Development) and so on and so forth. Developing these methods and standards takes a long time and some highly educated, highly irrelevant, highly decorated and highly paid guys in suits to decide whether they are up to standards or not. The development of these systems also follows a certain process that is followed by their products and their predecessors.

Rapid Application Development has always fascinated me, it appealed to me as I’m not the guy to sit down and talk a lot about what needs to be done and not getting it done. That is not what I’m talking about here. Here I’m going to introduce you to a new system development method.

RAD 2.0 — the chaos theory:

This is a new process developed over at the online labs over the last few weeks, it takes all the good things from the existing methods and all the wrong things from all over the place and puts them together to create something great.

Here are some steps to successfully implement this process.

Human resources: It is always best to get the lowest number of people to do the job, all you need is an enthusiastic strategist/lead developer and two equally enthusiastic developers to learn, teach and work with him. Then you need a general manager and a business manager to overlook the whole process and motivate the process. Then you are going to need two seasoned users of the system you are developing to sit by and go about their job with the legacy system that you are planning to face out.

Planning: A certain philosopher said that failing to plan is planning to fail, here you are advised not to plan, nothing what so ever. You can’t fail where you haven’t tried, therefore you can’t be planning to fail. All you need is a delivery date, preferably not too far away, so that you work under pressure.

Project management: This is not a problem — you have a general manager and a business manager with you, so they will oversee everything that needs managing.

Now that you have the basics, do not even note the project commencement date, just come in every morning and go about your business, remember that the deadline is near and start putting on extra hours –before you know it you will have a fairly functional system. Now to move it from fairly functional to exceptional, bring in some chaos, get a couple of interns to help with the donkey work of recapturing old data while you are trying to migrate data from the old system, and make sure you get the most reluctant of the consultants who were supporting your legacy system to help you with this process just to make things interesting.

Allow the interns and the users to make new requests as you go along and throw in junk food and a couple of beers during the late night development sessions. Be sure not to get enough rest lest you forget what you wanted to implement. Two days from the deadline, get all the stakeholders in the company to come and watch the developments, if you have kids, please feel free to bring them around so that they can unplug the machines as you work. It adds to the triple Fs of this method (Fun, Fatigue and Frustrations).

When you are done with this, look back at what you have achieved and smile. ‘It was worth it’.

This development is not cast in stone, it is one of the most agile methods out there and everyone is welcome to change as they see fit.