Fog Creek Software
Discussion Board

Development Methodologies

On Monday “muppet from” questioned developers about not specifying their development methodologies when they asked questions.

As the topic of that thread is about a specific diagramming problem. I would like to start another thread about this more generic issue. I would like to know if you really follow (to the line) development methodologies Or do you just use what you think is useful from one or more methodologies to do your work? Or you never follow any methodology at all.

I remember, years ago, my boss decided all developers should follow OMT + prototyping. So we all were trained in those. After some months we ended changing some things.  We didn’t like some diagrams and stuff and decided not to use them… and it worked well.  So, what’s your experience on this? Links to related previous threads will also be appreciated.

Cecilia Loureiro
Tuesday, July 13, 2004

I have a general background in diagramming, starting with JSDs and onwards to OMT and now UML.

However, I consistantly design stuff in notebooks, generally with diagrams of how things look (even when it is internal code; I really do 'visualise' non-graphical code too).

And that seems about the right balance.  Also, it looks cool.

i like i
Tuesday, July 13, 2004

>I would like to know if you really follow
>(to the line) development methodologies

Fact: No methodoligist is going to be able to describe what to do in all circumstances.  The best they can come up with is a leaky abstraction.  The thing about leaky abstractions is, well ... they leak.

Sooner or later, you're going to have a problem where your methodology tells you to do the wrong thing.  So you're forced to follow your methodolgy into foolishness, or say "Wait, no ... that's stupid.  I'm going to do blah blah instead."

The IT departments that can't seem to get anything done, yet have 500-page binders with glossy pictures on them?  You guess it.  Methodology madness.

I'm more of a follower of pragmatic programming.  Sure, methodologies can be helpful, especially to newbies.  Our goal is to grow senior programmers who know the best thing to do at any point in time, and do that.  Do methodologies help in that growth?  Sure. 

They are a great place to start, but no place to stop.

It's a lofty goal, but hey ...

Matt H.
Tuesday, July 13, 2004

The main thing, as I see it, is that "no methodology" is really still a methodology, just not a very good one at all.  So having any sort of thought-out plan is generally going to be superior to blazing in without one.

The key is to not try to fit square pegs into round holes.  No methodology or plan works in all situations, so you have to analyze your environment and select a method that best serves your needs.

I agree with what Matt H. says about methodologies being a great place to start but no place to stop.  On the other hand, I think that there is an established set of accumulated wisdom on how to go about developing software, and it is foolish to ignore this existing knowledge-base.

Jesse Smith
Tuesday, July 13, 2004

+++On the other hand, I think that there is an established set of accumulated wisdom on how to go about developing software, and it is foolish to ignore this existing knowledge-base. +++

I think that adhering too tightly to the "established wisdom" is a good way to strangle innovation and pigeon hole your development efforts.

I use bits and pieces of methodologies I find useful, and discard what I don't think is so useful.  I have the fortune to work in a rather disorganized shop where there is no "prescribed" methodology.  Now, this is both a blessing and a curse.  It's a blessing in that I can program in a sensible way that is intuitive to me, and hence be much more productive in my coding.  It's a curse for what are probably obvious reasons:  developers with no common sense or ability to visualize/design well organized code make an unholy mess of everything they do.

muppet from
Tuesday, July 13, 2004

I work on a web development team for an IT department.

One thing I've taken from McConnell's "Rapid Development" book is that there is not 1 SDLC to rule them all.

Different organizations have different people who can achieve results using different methods. A department can have a varying level of understanding across all of the different business units within a company. (Know more about the Sales side of the house and their needs, compared to the HR department and their needs. etc...)

Different projects can require differen SDLC's. Some may require iterative releases so business units can immediately start using SOMETHING, other projects may be meaningless unless the whole feature list is delivered. So your methodology for construction of these projects may be different.

My team has had repeatable sucess with a methodology/SDLC called FLiP.

Here are some links:

My story of my team's transition and usage of FLiP:
From Failure to FLiP

And check out McConnell's book, Rapid Development.

Oh, and yes we are currently using 1 SDLC for every project. It has worked. We're a young team and as our sophiscation grows, I believe our development processes will become more dynamic.

michael (
Tuesday, July 13, 2004

Every methodology you'll ever read about was pulled out of some guy's butt, usually as a means to sell books and/or speaking engagements.

On an individual basis, sometimes they work anyway, for a certain group of people.  And sometimes they fail spectacularly, for a different group of people.

Always be open minded about methodology and try to mold any methodology you do want to implement to the specific team you are trying to get to use it.

If you walk in with the attitude of "Oh, strict Extreme Programming solves all problems, lets implement it within our group!" and you don't allow for the fact that no methodology is one-size-fits-all, 99 times out of 100 you're going to crash and burn the project you're working on at the time.  If you happen to be the 1 out of 100 where It Just Works, you're going to be an extremely vocal evangelist of whatever process du jour you picked and think It Always Just Works.  But you'll be wrong.

Mr Fancypants
Tuesday, July 13, 2004

No single methodology can solve all your problems. There was an article many (20+ I think) years ago with a title something like "there is no silver bullet." There won't be some magical thing (silver bullet) to slay the werewolves you face, and it really is a waste of time looking for one. Think of it as the Goedel Incompleteness Theorem applied to programming methodologies. Or, if you try to make one, it will be so complicated that no one can possibly understand it all, which would make it the PL/1 of programming methodologies.

My advice: learn a few methodologies, what they are good for, what they are not good for. Then, when you are in a situation, you can pick what is best for the situation at hand. Yeah, I know its a pain, and a few years from now, only the old farts will be doing UML, and the new farts will be doing some new buzzword compliant methodology. It is like asking "what is the best screwdriver?" Because the answer depends on what sort of screw you are trying to use.

Are swimlanes good for projects of type X?
How about k-maps?
Would you use ERD for a non-OO, non-DB project?
State charts for a stateless program?

Tuesday, July 13, 2004

One reason I like Crystal Clear as a methodology is that it draws a clear distinction between things that the author has found to be important, and things which can be left up to the discretion of the team.  Things like which diagrams to draw, using which notation etc, fall into the latter category.  There are much more important things that make more difference and, IMHO, those are the things that a methodology should focus on.

John Rusk
Tuesday, July 13, 2004

My favourite methodology is JFDI, although not many clients like it.

Steve Jones (UK)
Wednesday, July 14, 2004

I have developed code for some time and one one ocassion I was supporting developers by writing procedures for the use of the system.  It was like trying to catch flies when you are blind.  Developers changed constantly the interface, the flow of screens and the database.  They said "we do not follow any methodology because it constrains our freedom".  In fact, they did what they liked and forgot about the user.  At the end, we had to rebuild the whole system as the lead developer left the company, did not document anything, programmed obscure routines and ended up crashing the unix server (he did not consider building programmes for garbage collection).  Some of these things could have been avoided if we had a methodology to make some sort of accountability on the software. 

Evolution and me
Wednesday, July 14, 2004

*  Recent Topics

*  Fog Creek Home