Fog Creek Software
Discussion Board




Building a process

I'm recently began to try to figure out how to put a process on what my team and I do on daily basics.  I red some specs here and there, and some documents here and there.  But nothing really out there gives me some sort of guideline as to how to put process around what we do daily.
Does anyone know any good resouces out there?  I remember reading something about software maturity model, but can't seem to remember what it is.

Unix2M$
Friday, June 25, 2004

Capability Maturity Model (CMM)?

http://www.sei.cmu.edu/cmm/cmms/cmms.html

Green Pajamas
Friday, June 25, 2004


Here, in my company, we have a browser-based intranet application for tracking project work done by teams and individual members. Its called Digital Workplace. Microsoft has also got one called Digital, umm..., I forget. That might be your best bet. Or if you have a small team, you could whip some code and create a simple Windows-app in VB connecting to a database server with a DSN on your LAN. Besides that I can only offer you a suggestion - read all of Joel's articles from his archive and you'll find some help there.

Sathyaish Chakravarthy
Friday, June 25, 2004

CMM doesn't define a process, it only requires that you have a process that is repeatable.

Same with ISO 9000:

http://www.iso.org/iso/en/iso9000-14000/iso9000/iso9000index.html

Tom H
Friday, June 25, 2004

http://www.martinfowler.com/articles/newMethodology.html

hoser
Friday, June 25, 2004

1. What kind of software do you build?
2. What kind of people do you have?
3. What are the expectations on your team?

These kind of meta questions will help pin-point
where you are in process space. The process for a router
is different than software for which is different from
web access to a reservation system.

son of parnas
Friday, June 25, 2004

paranas' son,

Thanks for the awesome link.

Ged Byrne
Saturday, June 26, 2004

I mean hoser.

Ged Byrne
Saturday, June 26, 2004

Here's a link that appeared on Slashdot yesterday, gives one person's view of the process at Microsoft:

http://blogs.msdn.com/David_Gristwood/archive/2004/06/24/164849.aspx

Tom H
Saturday, June 26, 2004

The "Crystal Clear" methodology may suit you well if your team is smaller than about 10 people.  It's based on research into successful small teams and is specifically designed to be easy to adopt.

See http://c2.com/cgi/wiki?CrystalClearMethodology

There's a book due out later this year, with the current draft available on line.  I rate it as one of the best things I've ever read about software development processes.

John Rusk
Sunday, June 27, 2004

PS. Regarding CMM, I think you'll find something like Crystal Clear much more effective. 

If your starting point is a team with no formal process, and you to try to adopt something "big" like CMM or RUP, chances are you'll expend a lot of effort for relatively little gain.

(Yes, I know than in theory RUP can be customised "downwards" to something quite light, but why not start with something that's light already!)

See the Preface of the Crystal Clear book for more info, plus the section of the book that explains how it differs from CMM and RUP.

John Rusk
Sunday, June 27, 2004

Just be careful.  CMM and ISO, while not specifically processes themselves, tend to: yield awful processes; accumulate and attract layers of management, "specialists", and other friction; severely alienate creative people like your better programmers; drastically harm productivity.

You'll find anecdotes and studies by the organizations that profit from CMM and ISO, including SEI, that suggest those mechanisms help.  Where they help are in horrible situations where dozens or hundreds of untalented and unintelligent people have been spinning their wheels act and acting rashly.  Such places benefit by slowing the pace to a crawl and involving several people in every decision so that no single buffoon can bring harm by making a stupid decision alone, and every step is taken slowly enough for slow minds to produce adequate results.

If you are serious about adding some useful guidance and discipline into an organization, explore the agile movement, which includes Crystal mentioned above.  (Google things like Agile Manifesto or Agile Alliance.  Some names: Beck, Highsmith, Cockburn, SCRUM, XP, TDD.) My advice is to look at quite a few of these, and find one or two that suite your team.  Unless your team makes such choices themselves, your results will be unhappy.  These are disciplines, and all discipline requires commitment.  You cannot force true commitment upon people.  You're going to have to sell this.

A common mistake is to read about one or more of these, and introduce a few of the practices without adopting the philosophy that makes those practices effective.  I tend to recommend teams immerse themselves in one of these disciplines, using every practice of that discipline before you start pairing away, modifying, and localizing it.  It's important to learn a proven tradition well before you create your own.  Ask Picasso.

Agres
Sunday, June 27, 2004

I can also suggest the pragmatic programmer series (http://www.pragmaticprogrammer.com/).  While not a "process" per-se, it's an excellent collection of best-practices.

Chip H.
Sunday, June 27, 2004

*  Recent Topics

*  Fog Creek Home