Some RAD (Rapid Application Development) Lessons

by phil on Thursday Oct 13, 2005 1:33 AM

working document

pliancy - Since you can't QA for every single case, and since you don't have the large user base yet to test for every case, make sure that every component is flexible and compatible in a multitude of situations.

time2legacy - When adding something to your codebase, ask yourself how long would it take for it to become legacy. You don't necessarily have to make everything scalable from the get go, but try not to make components that you think you might have to replace soon. The replacement process time increases by n^2 where n is the number of lines of code you have because the number of links and dependancies to that legacy piece increases exponentially.

maintenence load - How frequently will a piece of code have to change over time. And when changes occur, how much work is it for the developer?

semantics - The names of your functions and the logical organization of classes are so important in RAD. What I noticed is that in about two-three weeks I zoomed through the creation of a program. Then when I had to go back and make bug changes, I had to depend on function-naming cues to drill down to my code. Fortunately a good IDE like Visual Studio .NET makes it easy to jump from references to definitions. Usually if I see a bug in my program, I go to the UI designer then double-click on then control and then try to jump five hops to the part I need to edit. In other words, RAD happens so quickly that you'll leave a trail of code without any trail map. Hence the code should be intuitively easy to re-navigate. This is a given in any programming, but in RAD the need for semantic-clarity kind of jumped at me. I was looking at my own code as if a stranger had written it, and it's not that my memory is bad, it's that writing code and then getting acquainted with that code are processes that don't occur simultaneously. And the acquaintance part can even take longer. In other words, I feel I know more about my own code now, after having re-traversed over and over again through bug-checking, than I did when I first wrote it.

rapid isolation - ability to run isolate functions and run them without too many steps per iteration.

change impact - guaging the impact various changes to your code will have throughout the code. network thinking

RAC and RAM - There's rapid application creation. The speed cowboy-coder prototype builder. But RAM, Rapid Application Maintenence is important as well, and has its own separate methodology. It's so easy to make a demo, but then once the demo breaches the public, and new features are requested, and the product is evolving, how can you make that process really speedy.