Fog Creek Software
Discussion Board




Software Development Process

Joel, can you point me to a standard example of a software development process?

Genevieve
Tuesday, March 30, 2004

I've read your question several times now and I still don't understand what you're looking for, or why.

Joel Spolsky
Fog Creek Software
Wednesday, March 31, 2004

I think she's looking for a big M.

Sam Carter
Wednesday, March 31, 2004

OK, now I can honestly say that I don't understand either of you.

Joel Spolsky
Fog Creek Software
Wednesday, March 31, 2004

http://discuss.fogcreek.com/newyork/default.asp?cmd=show&ixPost=1912

Sam Carter
Wednesday, March 31, 2004

This great essay will answer the question I think is being asked.  http://www.joelonsoftware.com/articles/fog0000000024.html

I can't tell you how relieved I was to hear that the "right way" to do things doesn't necessary apply to me.  Now my arrogance has been properly vindicated. :)

Crimson
Thursday, April 01, 2004

A followup question would be:  Does  MS follow a development process?  They're big, but generally hire only smart people.  Smart people disagree all the time.  Maybe a standard methodology is a good way to keep the smart people from disagreeing as much...or on the other side of the coin, maybe there's no methodology that can do that.

Crimson
Thursday, April 01, 2004

I read this book called Microsoft Secrets. Not bad.

In it, yes, they follow a process (not methodology) and the process seems to be "Every team must have a process and follow it. The right process is the one that produces the right results for the product."

In other words, teams grow, shape and discover the way they like to deliver.

Suprising to see that while specs get written, they do not get signed off. Throught development, they produce little guide papers or memos one one area of functionality.

But that is that.

Patrick FitzGerald
Thursday, April 01, 2004

Process/methodology is a pet interest of mine, so I'll chime in.

Go read (skim in areas) the Unified Software Development Process (basically RUP, but donated to the OMG).  Then read Extreme Programming.  Two nearly opposite ends of the spectrum.

Then understand what they have in common.  Code reviews, planning sessions, testing to specs (or in XP's cases, testing forming specs).  Understand what advantages/disadvantages each is touting.

Personally, I tend to prefer more rigorous ("heavyweight") processes as my *template*, then rip out what isn't relevant to my project.  I think that you're more likely to get a good process if you've got a list of everything and trim down, rather than have a blank slate and try to figure out what processes to add.

Steve McConnel has a pretty pratical process in his Professional Software Development book.

Chris Kessel
Thursday, April 01, 2004

Genevieve: I've researched 'Standard Processes' (aka Big M Methodologies) since around 1978.  Keywords like DOD2167, IEEE-498, and IEEE-12207 document a few of the 'Big-M' Methodologies.  You might want to google those.

The Carnegie-Mellon University SEI (Software Engineering Institute) CMM levels (Capability Maturity Model) also enter here.  Also, the Watts Humphrey "Personal Software Process" (Mr. Humphrey used to be associated with SEI).  Rational has the RUP (Rational Unified Process) to go with their UML diagramming for object-oriented development.

The big problem you'll quickly run into is that NONE of these processes can run without tailoring and customization.  Very few of them are 'light-weight' enough to HAVE a simple, complete example. 

Any examples that ARE built can't easily be compared, because they are proprietary, or the tailoring make comparison hard, or the domains are so different.

I hope I've given you a start, though.  Of recent development (in the last 3 years or so), I'm getting quite fond of the Extreme Programming (XP) school of thought, as well as the Agile Modeling approach (Scott Ambler) which tries to unite some XP with UML.

AllanL5
Thursday, April 01, 2004

Check out Alistair Cockburn's writing:

http://alistair.cockburn.us/

His Crystal Clear methodology is based on extensive research into what successful teams actually do.  In common with several other postings to this thread, his methodology states that during each project, the team should adapt the methodology to suit what works for them.

Another important point is that it starts simple.  Unlike the RUP approach, which gives you everything anyone might possibly need, then you have to cut it back down to something that suits, Crystal Clear starts simple.  You can build it up later if you want.  I think this will make Crystal easier for many teams to accept and implement.

John Rusk
Sunday, April 04, 2004

I use SSADM (because the management process are really good) and have flicked in my own methods as well. I've adapted this core with OO stuff and some ISO/CMM stuff to bring it up to date.

Another one that is good is WSSDM (IBM) but you have to be on the ball with OO project management.

I'm not keen on any of these modern hack methods such as rup, extreme etc.  They just seem to be done by a bunch of egos without any actual experience or what they do have is made up of running small product development cycles with 10 man teams.

Andy Watson
Wednesday, April 21, 2004

*  Recent Topics

*  Fog Creek Home