Rapid Application Development vs. Big Design Up Front

I’m working on a new project which I regard as medium-large in scope, and I’ve decided to use BDUF instead of RAD on it. This is of course heresy in light of the effect XP and Ruby on Rails have had on the web startup zeitgeist. (“Isn’t it all about RAD these days?”) But I still think I’m making the right call here.

I’m biased toward lightweight processes and high diligence, I will admit. So I’m pretty much a centrist by default, not wanting to do tons of paperwork nor to use super all-encompassing Tools Of Doom, but also not wanting to just open up a text editor and start hacking before I’ve thought something through. As far as I can tell, no formal process recommends either extreme, but they do clump toward one side or the other.

My take on BDUF is not to implement RUP or FDD or TDD or any named process as is, or even customized according to the Official Tome of that specific process. I believe that the best process is the one invented by the software development process expert on your team, tailored to fit the specifics of your project. That would be me. Hopefully that guy has read quite a bit about named published Official Software Development Processes, which I have.

So, in my case a process that employs some BDUF is not filled with bureaucracy and boilerplate and meetings and signoffs. Really it just means that I’ve taken long detailed notes on feature ideas, and that I’m doing wireframes (a.k.a. page schematics) and use cases before coding. I plan to do a page schematic for every page and a use case for every darn thing in the system. If the page is simple, then hey, it shouldn’t take too long to do a wireframe for that page should it? If the use case is simple it should be trivial to write.

In thinking about this I’ve come to some general conclusions about RAD vs BDUF that I’d like to share for the good of all.

RAD is not the next step in evolution beyond BDUF. RAD is not stupid and lazy compared to BDUF. They both have their place. Here’s how to decide which you need to favor in your roll-your-own process:

1. Do you have a clear vision within your team for what the product will be?
2. Is there a very solid understanding of the problem domain, within your team?
3. Do you have stakeholders and/or investors outside the core team who demand to control the design of the product?
4. How much overlap is there between the software people and the domain expert people in your extended team?

RAD works really well if the answers to 1-2 are “no”, 3 is “yes”, and 4 is “not a lot”. It helps a lot to build something that you don’t fully understand if you have some realistic prototypes to let domain experts and stakeholders fiddle with as you build it.

The disadvantage of RAD can be that the amount of rewriting effort is high. That may be unavoidable but it might be better to do high-fidelity page schematics (basically, a large number of comps) or even an HTML mockup instead of wireframes, rather than actually trying to make it all work before your stakeholders and domain experts have had a few iterations to poke and prod at.

One middle-of-the-road technique I learned from former co-worker Mike Schierberl is to just start with an HTML-only prototype and just “grey out” the links, buttons, etc that don’t work yet, or the content on the page that’s hardcoded or comes from a canned stub function in the back-end. That allows a stakeholder to just poke around the application and see what works and what doesn’t, which is a lot more useful than a couple of bulleted lists of done/not done. That gives an indication of progress as well as letting you just do HTML before stakeholders look at and comment on your proposed design. As parts of the UI become better understood, you can code them, and the mockup and running code coexist in the same running instance. When the mockup is gone and it’s all working code, you have an approved prototype that you can clean up for launch.

BDUF works well if you have a pretty darn good idea of what you want and you have the talent within the team to make decisions about the stuff that hasn’t occurred to you yet. At some point you absolutely have to make decisions about the lowest level functional and UI details that you’d rather not have to deal with, but computers can’t fill in the gaps in your high level design. The point of BDUF is to have all those conversations and design sessions in the cheapest medium possible, which is usually some words in a word processor about what it will do, and some annotated low fidelity pictures that describe how it will look and feel.

The disadvantage of BDUF is that you can get pretty far down the wrong path with no feedback. Stakeholders get impatient when they see that you’re producing a bunch of requirements gibberish instead of writing code. Wireframes and comps can help somewhat but that depends largely on the level of imagination that the stakeholders have, and their trust in your good judgement about design, and their experience with software applications that you consider to be well designed. Non-software people who just hired you aren’t going to have much patience for a 4 month design phase on their nickel, especially if you keep emailing them 150 page .doc files full of use cases that they’re supposed to review.

In my case the answers to the 4 questions above are “yes”, “yes”, “no”, and “a lot”. Those are the opposite of the answers that point to RAD as the right choice, so I’m using BDUF this time.