Big Requirements Up Front

by Phlip

Even using the right tools, in the right way, a software project can still get into trouble. One of the most pernicious ways to fail is over-specify everything up front. As the "Lean Software Development" movement has documented, well-intentioned people often add risk to their projects when they make hard decisions too early - before any research to identify any supporting facts. The best practices are Adaptive Planning, and Just-in-Time Requirements.

Another way to fail is to allow these requirements to fall into your lap by themselves. This post explores why embracing these deceptively easy requirements still adds risk.

6 Comments

Tom
2007-09-25 05:48:50
This article has a familiar ring to it. :-)
Paul
2007-09-25 07:50:09
I think we all know the exact situation you are referring to here, and I think there's much more to consider here. Your final statement about blaming platform Q may be incorrect. It might have been platform Q's fault after all that it wasn't used. Maybe the methodology in developing platform Q didn't take Vu's business process into account when it was written. Maybe platform Q didn't provide the optimization that was needed. Maybe it just wasn't the right tool for the job.


Or maybe Vu's original language gave him the control he needed without the need for a third party framework

Phlip
2007-09-25 09:58:10
Yeah, and that post was being written at the exact same time as I told my client, new to RoR, that people who switch from whatever he was using before to RoR don't tend to switch back.


Uncanny, huh?

Spacemonkey
2007-09-25 14:52:06
Maybe this isn't about the technology at all, but the approach and skillsets involved.


Let's be honest here - it doesn't really matter if we are talking about PHP, Ruby, Python, Java - all of these are mature enough to handle most needs of a website. It would have been a totally different conversation maybe 10 years ago, but now you pick what you're familiar with, not what's trendy.


For the record, I started in Perl, jumped to Python (and later Zope/Plone), got pulled into PHP, snuck over to Ruby/Rails, and now just use what is needed. The website in question probably could have a successful re-implementation in whatever language you chose; but a complete implementation in a language that's new to you, is never going to be as fast or effective as a refactoring in a language you're quite seasoned with.


What disappoints me is that there are no real details in the original article, so anything anyone has to say about the matter is purely conjecture.

MikeFM
2007-09-26 01:11:59
In the project I'm currently working on the hardest part hasn't been the design or programming - it's been that we have to tie in with a complex 3rd party legacy system that is poorly documented with buggy interfaces and some serious functionality gaps. It's a system we can't replace so the development process has been a lot of trial and error. The project has overran it's original timeline a little but a lot of the legacy issues have been figured out and documented so I don't think it's a real issue. Now that we understand the legacy system better adding new functionality will be much easier.


The biggest question for me is how much of this documentation and tools should be made available to others outside our company. Many mid to large businesses use the same legacy software and we could save them thousands of dollars in development costs on their future projects but what benefit is in it for our company?


2007-10-04 06:37:08
The scenario described isn't too bad: both developers are skilled enough, they have enough time, platform P and Q are both appropriate, requirements are stable and reasonable, the product is working and satisfactorily in use, the company and customers don't mess up the project...