Late Night Musings 10/07/98 02:16 Some thoughts on RAD I had a phone interview today. When it was over the fellow on the other end of the line said he didn't think I'd be happy there, since their requirements were often really soft, and that I was too rigid to deal with thier style of development. I had to think about it a while, and realized the problem was that I had talked about my current habits for 'getting work done' and that what I described was more or less the rather stodgy waterfall model, and that somehow he felt this objectionable. I thought about the implications of how he described thier operations, and conclude, "Oh, they're a RAD shop." Pause. "Or more likely, they _think_, they're a RAD shop." RAD has some solid theoretical underpinings. It also has some desirable practical advantages if done successfully (shorter time to market, high customer satisfaction due to percieved responsivness). The ability of properly implemented RAD to produce a steady stream of "basic functions", "new feature", "new feature", "new feature"... is it's most attractive benefit as well as it's most visable characteristic. Unfortunately the steady production of new versions does not require, nor does it indicate, a successful RAD implementation. Additionally I see RAD as possessing a great shortfall. RAD takes more discipline and diligence in general and in specific a greater effort in implementing change control (because there is so many more changes being made) than traditional (waterfall?) development cycles. But those places I know of that have adopted RAD have done so, at least in part, because they've failed to meet thier goals using more traditional methods. The primary cause of failure is the inability to effectively enforce the formalisms of their lifecycle. "It's too much work, we waste programming time in meetings or document prep. We need to see results faster so we'll implement RAD." Why do these people think they can fly when they've demonstrated an inability to walk? Successful RAD requires one "get it right the first time", because it will be released so quickly. If you can't get it right with a complex system of checks and balances you have no hope of doing so without that safety net. If you can't get your programmers to write down thier designs, how will you track the frequent changes and side effect of those changes the way you need to to successfully implement RAD? If design and code reviews don't prevent software from spending weeks in QA because of defects, how are you going to produce reliable software when you only have a week to do your testing? In those cases what "RAD" amounts to is accepting the chaos of uncontrolled development and pretending that there is a method to the madness. Instead of RAD they have TED "Trial and Error Development". To me it isn't clear that this is an improvement over pre-structural/lifecycle techniques, because for the most part it is a reprisal of the original ad hoc design and code techniques used at the dawn of programming. These people are able to fool themselves into believing they are doing RAD because they are releasing a new set of bugs on a regular schedule. Conventional development, with it's discrete seperate steps and documentation requirements does slow down software development. Each set of documents and reviews jars the smooth flow and limits speed much like continuosly using the hand brake. The distinct advantage to this is the cart is still in one piece when you get to the bottom of the towpath. The few people I've talked to who feel they are sucessfully using RAD, still leave me with a bad feeling. They're putting in new features and releasing them to the users every week. They also introduce new bugs most every week, and sometimes the weekly release consists solely of bug fixes caused by the last feature addition. The "Rapid" part of the development cycle pretty much precludes adequate testing, but nobody cares about the bugs, because "we'll patch them in the next release, the users will only have to deal with them for a week". In these cases when I asked how the users felt about this the response was that the users were happy because they could ask for new features and get them in a couple of weeks that they didn't mind the continuous bugs. When I pressed a little harder, I got the impression that most of these new features were in fact sugar coating on existing features. Enhancements and refinements were continuous. Substantial new capabilities were actually produced only slightly more often than a normal commercial release schedule. Working in a RAD shop would be an awful lot like being a busboy at a fast food place. You wipe down the tables. Now the floor needs to be mopped. By the time you've finished mopping the floor, the tables need to be bussed again. And so on. What you've done is nessecary, even vital to being successful and making a profit, but at the end of the day what have you accomplished? In RAD/TED, you've polished the code a little, maybe added some chrome to the UI, and once and a while you get to bolt on some tail fins. But it's still the same application. If you're actually (knowingly or not) using TED then you also have the knowledge the application still not what it should have been in the first place. In either case, users are insatiable for new features, so there will never be end to your efforts. In addition to that demoralizing effect, a RAD process places you in perpetual crunch mode. Wether your release dates are weekly or monthly the effort needed to meet the schedule will be scaled accordingly. There's no getting around the tension of "we need the new version by friday". Even if the schedule is modest enough to actually allow sufficient time to complete the work needed (yea right), nobody can sustain the stress levels associated with _always_ being up against the deadline indefinitely. Sometimes I suppose RAD is the only choice: Your users have no idea what they really want, and you don't understand thier business well enough to pry it out of them. You need to put something together ASAP, so they can say "Nah" repeatedly. But once again RAD is a misnomer, you're still doing TED. My current project is more or less forced to RADish behavior (TED really, but that's because we inherited a lot of iffy code from ad hoc methods and a raft of politics. I'm trying to push us towards a streamlined waterfall process, but probably won't succeed until we get the current stuff stable and are given the go ahead to work on it's replacement). We interface to a database on the backend, where said database is under concurrent development. Every week or so they release a new version (I guess they're a RADish project too). Every few weeks our application breaks because they've changed the interface. Of course when we try to fix stuff we get the "by the way can you put this in while you're there". It doesn't help that while we are only supposed to be fixing bugs so that the application no longer requires full time maintenance, the help desk people have a very fuzzy (and suspiciously convienent) understanding of the difference between bug and new feature. In a lot of ways this is exactly the sort of situation that RAD is intended to deal with, but the lack of a solid, modular, well designed code base makes every change an adventure, "How the hell did this _ever_ work?" is a common phrase. Research or blue sky projects also are a clear home for RAD. You don't know whats possible or not so you keep trying stuff until you're so far out it doesn't work anymore (or keep backing off from the impossible until you get something that works). Either way frequent proof of concept releases grounds the wildest theories in reality, and provides reference code needed to pass results off to a more stodgy team for development into an actual product. I can imagine a perfect situation for RAD in normal application development. A place with software architects are so skilled that their design is so modular and the APIs between modules so artfully designed that major components of the system can be replaced without ever effecting any of thier dependants. A place where all the programmers are brilliant and diligent, and everybody white boxes thier code before returning it to the repository. QA never returns a function due to bugs. In those rare cases that bugs do appear, the code is well documented and programmer B who just finished adding his newest feature, can fix it, because the originator A is busy adding a new module. A place were the communications between all the people working on the project approaches the 2N+2 links, with little latency. I can imagine such a place, but I also imagine they haven't bothered looking at RAD, because they're probably doing just fine with whatever technique they've been using. On the other hand anyplace that good is probably in the process of dropping RAD in favor of the "next big thing" which they've already figured out and the rest of us will be hearing about in a couple of years. I guess what sorta ticked me off about the 'dismissal' I got this afternoon is that I was left with the impression that I had not used the right buzzword, and therefor wasn't the right guy to help them apply a magic formula. Once again form over substance reigns. The fact that RAD is not a magic formula that eliminates the need for exacting and disciplined effort in a development project, and anyone that is well versed in older methods has the skills *required* to be successful with RAD, even if that's not my first/default choice of methods (for good reason, I might be able to do RAD, but what about the rest of the team?), seems to have just passed this fellow by. I suppose my point is that the main difference between RAD and the more meticuluos waterfall type development processes is that in order to do RAD, you have to be so good at the steps involved waterfall process, that you can do them repeatedly, for each feature release, within the same time period you would otherwise do it once. In addition to that you have to add an uber-design step in which you figure out the synthesis of critical path of the features (feature B depends on feature A) and the user demand for them. The main advantage that theoretically makes RAD easier is that since you've divided the project into baby steps, each repetition of the waterfall for a given milestone should be easier to do right. Copyright © 1998 Jeffrey A. Holmes All Rights Reserved. No duplication or distribution permitted without prior arrangement with author.