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.