From my experience, which is admittedly tainted with many bad RAD experiences, the term ‘RAD’ or ‘Rapid Application Development’ has come to mean ‘Bang on the keyboard and mouse as absolutely fast as possible to get through all the features you can and then have a major death march hero bugfixing party near the end of the project and then ship it and hope for the best.

     When the stakeholders come back after a week and say, “That was great how you guys got that out so fast!  Now we need a bunch more things (2x the features) and we need it faster (75% of the time of the last project)!”  and then most of the team quits or finds ways of bailing out of the project and leave it the new guys or the junior developers who didn’t have enough experience to see it coming. The majority of my experience is similar to this, as a matter of fact. This is probably a major reason why I favor and strive for sustainable, maintainable development practices and principles and more Agile (which, to me, means ‘realistic’ and ‘communicative’) management and process techniques.

Fear of Functionality

     I would contend that this style of development — focused solely on the next deadline — leads to tremendous amount of waste.  In most of these projects I’ve been involved with, the idea was that you put a bunch of planning and effort in up front to manage where the project would head and then deal with the crisis that come up throughout the project. While not totally worthless (some planning is required no matter what methodology you use, obviously), much of the plans and designs drawn up were quickly out dated and not relevant to the current state of the project.  Much of that time was ultimately wasted — time that could’ve been spent producing software. 

     Many people would stop me here and argue that much of the software written during those phases would’ve been thrown away also. This is absolutely the case every time I’ve tried it. But the point is that by writing software and refactoring it, I actually learn about the business problems as well as the software design and architecture problems much faster. The stakeholders can usually see things faster and raise any red flags or major misunderstandings earlier on in the project.  The throwing away of code is what some people bristle at. I believe the reason for this is that they’re not writing and designing their code to be easily thrown away or repurposed. Their code is inherently coupled and scattered throughout the project. They are, essentially, frightened of major changes because their code doesn’t allow easily for changes.  In order to change feature XYZ, you have to touch 27 files in a major way and rip out huge swaths of business logic in 3 parts of the system.  I believe that this is the core, fundamental problem and leads to much consternation when I argue on behalf of rapid, but sustainable, code development with a heavy emphasis on refactoring.

     The short of it is, if you find yourself uncomfortable when your stakeholders come and propose major functionality changes to the app and you find yourself arguing why XYZ feature is prohibitively difficult due to how the code is organized, you made a big mistake somewhere early on.  Don’t panic, though, there are some real, tangible things you can do right now in any code base to start making a difference!

Virtues of truly rapid, but sustainable development

     So you might be thinking, “OK, Mr. Smarty Pants, what do you folks do to your code that makes it so magically superior to allow you to turn on dimes like this?” The answer is not the code, but the way the code is built and the various chemical trails and signal flares we leave behind to make sure that we can easily change major functionality with high confidence of preserving functionality.  So