My Photo

Your email address:

Powered by FeedBlitz

April 2018

Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
Blog powered by Typepad

Become a Fan

« Custom Software Scope Changes (Not) | Main | USC School of Cinematic Arts, "Imagine the World in 2050" »

April 24, 2008


Feed You can follow this conversation by subscribing to the comment feed for this post.

James Taylor

One of the best comments on this topic was made by a colleague at Ernst and Young when he and I were both working on methodology and CASE tools. He compared software to buying a house - prototyping is like visiting houses, specification/blueprints like writing a list of requirements for your realtor. Just visiting houses until you find one you like is not going to work but any attempt to right down exactly what you want without visiting any houses is not going to work either. So, specify enough to visit the right kinds of houses and expect those visits to keep changes your requirements until everything stabilizes.
You must, in software, build specifications and blueprints but you must also prototype/simulate to make sure those blueprints are correct. CASE tools failed, in part, because they could not do the simulation piece.
Author of Smart (Enough) Systems

Jay Levitt

[Disclaimer: I'm a big proponent of the agile philosophy, but I have yet to try it on a big, critical project. That said...]

Are you sure?

Every time I've done a large, complicated project using the old Big Requirements Up Front (BRUF) method, two things happened:

1. The planning process took so long that, by the time it was done, our requirements were out of date. This is what I call a "physics problem" - it can't be solved. Every day you spend working on the paper version/prototype is another 24 hours for the real world to change.

2. No matter how much experience we had with similar projects, and no matter how many experts and eyeballs we had working on the requirements, we always, always, always missed something major - something that became evident within a week or two of actually rolling out the system. People just don't use a prototype the way they'd use the real thing. They don't even use a beta test the way they'd do the real thing. You don't really know what's missing until you roll it out to the Big Lab.

Obviously, a lot depends on what tools you are using. If you're working in assembly, C, C++, even (especially!) Java, then yes - you have a huge investment in your current architecture, and you're going to try to get from A to B with the least possible pain.

The current trends in dynamic languages are towards frameworks and development tools that make it painless to get to B the *right* way - no compromises. You're spot on with the "as close to zero investment" comment; what you may not realize is that it's now possible to write the *actual application* with near-zero investment in its infrastructure.

If you can change anything you want at any time, you don't need fancy prototyping tools; the prototype is the software. You get it running, and then you get it right. This won't work for the space shuttle, or any other embedded, non-updateable apps. But it works fine for server software, and for client software that can download its own updates.

Considering how attuned you are to the psychology of software, I'm surprised to hear you trumpeting BRUF. Yes, perhaps if we had perfect tools and perfect testers, it would work better in theory. But we don't; we have human developers and human users. And they work better with the real thing in their hands.


Just came across your blog post, I had done a similar post a few days ago, BTW it was about the need for a easy to use RAD protoyping tool that could stand the test of time

Sean B.

Having seen both approaches (BRUF & Agile) flounder and fail, I've come to the conclusion that a slavish devotion to any methodology leads to unavoidable compromises in planning, too much focus on the process rather than the project, and poor behaviors related to decision making and the inevitable project changes.

I too look forward to greeting our future automated overlords of software development, but seeing so little progress in the industry is discouraging. Are Intellisense and syntax highlighting the best we can do?

Hop Guzman

Rapid application development have their own place and is popular too but the problem is that it takes more time to deliver a product due to which requirements are changed in between and whatever was required is not exactly delivered at the end in most cases.

The comments to this entry are closed.