Design Methodologies discussion

[Wow, 3 posts in one day... it's been awhile since I've had one of those days... I guess I'm feeling a little less stressed about my current projects.  BTW, don't get used to this.  I'm moving on Sunday/Monday, so I'll be without Internet until next Tuesday (I'll probably my machines at home offline starting tomorrow evening)]

Anyway, I've been thinking about something.  I once wrote some ad copy for a component that started with the line “My father always taught me to use the right tool for the right job“ (he did, BTW).  I'm thinking that we need to adopt development methodologies based on the project.  We need to figure out what is best going to suite a particular project/engagement and use it. 

I know that I've criticized extreme programming.  I think a better criticism is that XP works in certain environments (and maybe only on certain projects).  I do think that XP adds a number of tools that can be pulled out and used (Test-Driven can be very effective... I don't buy into it for every project).

The “shop“ that I'm in is big on RAD (Ok,we're souring on RAD because RAD has become the buzzword around here for no methodology... no process... “just start coding and I'll go find out what they want“).  There are some interesting things that RAD adds to the equation.  (my understanding is that) RAD says don't do big projects... do small projects that you can easily get requirements for and do the project; release the code, then refine the project with the users (very quick releases).

The greater part of IT here uses SDM which is very process heavy (requirements docs are gathered; design docs are created; sign off happens on all items before coding commences.  When code is ready to be delivered a whole new slew of new documents are created -- and so it goes).  Process is good when you want to make sure you get it right the first time; the downside is that it takes a lot longer to do (BTW, we're moving back to the SDM methodology, as well).

Anyways, as I look at it, there are times when each methodology has it's merits.  I think our managers need to take the same approach that my dad outlined to me... choose the right tool for the job... or better said identify which methodology will work best for this project and use it.

[Kind of a boring post... I had to get it out... I go through phases where I have to write...]

 

Print | posted on Thursday, August 05, 2004 5:03 PM

Feedback

# re: Design Methodologies discussion

left by at 8/6/2004 6:49 AM Gravatar

Unfortunately, I've never been involved in a successful project that used SDM.  I've taken to writing "just enough" documentation to get the job done.  Sometimes this means a full requirements document + design documents, but most times it means document the requirements that I know and then a quick document that explains some of the technical issues and how I *think* I'm going to solve them.

<br>

<br>

Title  
Name
Email (never displayed)
Url
Comments   
Please add 8 and 4 and type the answer here: