Schedule and Events

March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email:

Wednesday, October 25, 2006

Post-Modern Software Development

About a year ago I had an interesting discussion with Jonathan Kohl and Mike Kelly about modernism vs. post-modernism. My assertion was that the Software Engineering Institute was the last holdout of modernism in the software world, and the loud voice of the SEI was holding back, even mocking the advance of post-modernism for software.

Post-Modern Software Development is in it’s infancy. It’s inspired by a talk Larry Wall gave a the perl conference , by Context-Driven Software Testing, and by conversations I have had with Jon Kohl and Mike Kelly.

On my way back from the IQAA Conference, I listed to a podcast interview of Jason Fried (of Basecamp fame) that basically defined post-modern development.

The twelve-or-so principles of the Post-Modern School of Software Development:
1) Analysis, Requirements, Design, Coding, Test, and Deploying are not phases, they are activities.

2) Analysis, Requirements, Design, Coding, Testing and Deploying are not roles or jobs either, they are activities. (But we allready said that)

3) If anything changes, you end up implementing all activities throughout the project. By the way: In business software development, stuff changes. This means that there are basically two ‘phases’ to development: Pre-Release and Maintenance.

4) Maintenance is a lot bigger than the academic success literature implies. To support maintenance projects, get good at regression testing. To do short cycles and quick releases, you probably need test automation of some type.

5) What the customer wants is going to change. Get used to it; make sure your process has a way of dealing with it.

6) Consistency is fine as long as it is helpful. We are not overly concerned with enforcing consistency when it is not helpful.

7) If what we used to call 'phases' are really 'activities', then knowing how to do more than one activity is probably helpful.

8) Job titles are fine, as long as they are helpful, not excuses.

9) The industry has spent decades trying to refine job descriptions to make them reflect reality, yet I have never seen an accurate job description. Ever. Why bother?

10) Simple and working (generally) beats perfect and in development.

11) We use other principles (classic, baroque, romantic, modern) when they are helpful

12) Vision is important. We’ve all seen the MP3 Players with 59 features that no one can figure out how to use, and the iPod that just plays music and speech. Do one thing, and do it well.

I just made these up. Eventually, I’d like to present them somewhere (perhaps IWST or GLSEC), build some consensus, and get them adopted as an actual, well, thing.

Then again, do we really need another buzzwordy manifesto-thing? Probably not. Personally, I am more interested in the discussion.

I covet your feedback.


Steve Freeman said...

I'm afraid someone beat you to the concept, see

Anonymous said...

Good Stuff buddy
I thought the information above has given me great topics to think about. Thank you!
Best wishes,
Software developer

Anonymous said...
This comment has been removed by the author.
Anonymous said...

Quite Useful Stuffs.. Thanks for sharing..


Anonymous said...

You have got nice perception.
Every book teaches them as phases, what you call activities. I agree to your point to some extent but how will you get this thought out.
even if i advocate your words in public, i will be considered fool if speak your thinking infront of anyone.


Anonymous said...

Gud sharing of your thoughts an knowledge also, You explained all the phases for the Development Project.
Good Approach...

All the best...
Meenu Sharma

Anonymous said...

Nice Tips