Software Methodology Tussles Concluded

In computing’s earlier days some 25 to 40 years ago we had a big tussle on for software development methodologies. In 1993, I and another Honours Student wrote about some research we conducted to catalogue just some of them, and yes there were a lot, and we produced this paper in all its student glory (part 1 and part 2).  I don’t have the electronic version anymore, rather the scanned copy which I somehow manged to divide into two sections during the scanning process i.e. paper jam.

We started with methodologies that were somewhat driven by the technology at the time.  For example procedural based languages created a number of Structured System Analysis models like Edward Yourdon’s (Modern Structured Analysis) also covered by Meilor Page-Jones’s famous book Structured Systems Design.  Information Engineering was somewhat data driven and made one of its originators a lot of money that he was able to live it up on a Carribean Island for the rest of his days.  Some, fortuntately did emphasis the people side of things.  The paper acknowledges this as generations of methods emerged.

This is where we have got to today.  People still create software and usage of ‘guides’ like Scrum, Kanban and some hybrids specifying varying levels of details recognise this.  Various prescriptions work in different contexts and our job as developers of solutions is to apply the right methods.

Furthermore the prescriptions I’ve seen attempted over the last 20 years have all been, to put it bluntly, been terrible.  Rational Rose’s Object Oriented View of the World was an improvement but still smelt of documentation beauty rather than delivering real customer value.  Consulting firms tried to market their methods and created massive tombs of unreadable text that no one bothered with anyway.  I remember reading in 2003 DMR’s (now Fujitsu Consulting) massive metholodolgy – they must have been thinking that execution word for word would produce the system everyone wanted.  It never happened quite the way the authors expected.  Prince2 is a repackaged variant of documentation heavy methodology which seems to be implemented by automatons keen on producing wonderfully thick documents with idiosyncratic diagrams and prose of the authors own concoction and no one else’s that should be filed in fiction in the library.  I’m not sure the claims that Prince2 can coexist in an Agile environment, the way I saw it implemented says no.  It could’ve have been that they didn’t understand that cross functional teams, a backlog, a willingness to create working software early and regularly and to break dependencies is critical to it’s success (credit to Mike Cottemeyer to making this stark).

Agile is certainly an improvement, but as we learn more about human interactions we can expect more improvements in the coming years. As for a tussle, it’s still a tussle given the way I observe the interchanges amongst Scrum, Kanban and the various scaling approaches.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: