John Cherry's Weblog

Project development methodologies fall on a continuum from the structured waterfall approach to extreme programming.  I have worked on all of these in my career. The industry is not abandoning all structured methodologies for extreme programming methodologies.  Methodologies are being chosen on a variety of criteria.  Let me say that the type of development methodology chosen is based on business constraints, span of control, and sharable technology.

If a company is developing a proprietary product that is linked to a business deliverable, the methodology chosen is likely to be a very structured, possibly a waterfall, approach.   The process is likely to look something like this...

• Company decides to produce product x by timeframe y
• Company uses inbound marketing resources to define what the product must look like.
• Company puts a development methodology in place, from functional specification to final test that meets the timeframe needed.
• Company assigns a project manager to kickoff the process and make sure all the resources are in place.
• Company starts the functional, design, code, test waterfall methodology, complete with spec reviews, code reviews, and test audits (would make the ISO crowd happy).
• Project schedules start to break down (plethora of reasons).
• Process compromises are made.
• Product features and capabilities are compromised.
• Product quality is compromised...or the product is released as a "beta" for a longer period of time.
• Product revisions, product support and product redesigns take much more time and resources than planned.  In fact, if the product was not release prematurely with compromised quality, development resources would be available for the next product rather than in fixing the old one.

I left out the very last step because it is very unpopular.  Usually the project manager and other innocent developers are casualties when the product blows up in a demo at the trade show.  :)

This is a pessimistic view of the proprietary, waterfall approach, but companies continue to use it, they continue to be profitable, and they continue to justify it from a business perspective.

The open source business model says that rather than to have 10 companies developing the same baseline software, let's pool resources and share the commodity components (below the value line).  While this pools resources and shares the development load, it reduces the span of control for any one company.  Heaven forbid, delivery schedules could be at risk! :)  While companies may feel a loss of control, if the components are truly shareable and if the developers have a business or personal interest in the product, the results can be faster development time, better testing, fewer premature deliveries, and more freedom in what can be done to the code (impacts spin-off projects, sustaining, etc.).

Of course, extreme programming removes all constraints and just lets programmers produce code, recode, re-evaluate, recode, etc.. without any real or artificial boundaries.  Smart companies that employ traditional, structured methodologies leave some room/budget for open source and/or extreme programming methodologies.