Interesting - IT procurement is increasingly looking like it will be reformed in the wake of the Healthcare.gov debacle:

http://www.federaltimes.com/article/20131201/IT/312010002

Kurt Cagle
Invited Expert, XForms Working Group, W3C

Managing Editor, XMLToday.org

kurt.cagle@g...

443-837-8725

On Mon, Dec 2, 2013 at 2:55 PM, Stephen Cameron <steve.cameron.62@g...> wrote:

According to some folklore I read, waterfall was discounted early by the guy who first described it, but it was too late, managment types had latched on to it, seeing it as a way to transfer the discipline of production line manufacturing to software development.

Its also interesting that one thing borrowed from another field into software development is "patterns", which comes from Christopher Alexander's 'A Pattern Language', he is an architect. In its original form its very much concerned with the human element, saying basically that patterns develop over time, and come to be commonly recognised as such, because they work well for humans, not because some specific designer thought they should work. So, they became the 'repetoire' of the builders who were the designers too, that helped to ensure success in new projects.

The reason I like the film analogy is that it is  focused on the human element first and the considerable technical details are subsurvient to this. To be successful films have connect with humans, we have to empathise with the characters. This is sadly why crime drama is such a common thing, they are cheap to make and guarantee a connection to the audience. How often have you found yourself thinking "this is crap" but cannot turn it off (thinking Midsomer Murders).

While computing started out as a mathematical discipline, and technically still is, it has moved into another realm, which is the extension of human and organisational capabilities. The first is something that Steve Jobs understood very well I think, understanding that combining new platforms and human desires/behaviours creates enormous possibilities.

So, we can blame politics and capitalism etc. but fundamentally these are human creations, cultural patterns of a sort, and derived from intrinsic human behaviours, this is where the problems and solutions lie I believe with software trainwrecks.

Old patterns of doing things don't work (probably most pertinent are top-down command management and contract based agreements on scope). In my local case, you'd have to guess that an academic institution trying to develop a complex piece of software is not the most likely place to find a success story. Probably too many fondly held opinions and little cooperation or ability to question- or to experiment with changes to - the status quo.

Maybe a failure is actually necessary to be able to acknowledge these facts and then that failure contains the seeds of success in a second attempt. The failure becomes a discarded prototype. What is perhaps worse is something that is "made to work" because of costs already committed, but which then is a nightmare for ongoing refinement (maintenance is a bad term from waterfall). This is what Domain Driven Design is aimed specifically at preventing I understand.

-Steve

On Tue, Dec 3, 2013 at 2:52 AM, Michael Sokolov <msokolov@s...> wrote:

On 12/02/2013 10:24 AM, Thomas Passin wrote:

On 12/2/2013 2:09 AM, Stephen Cameron wrote:

I think you are getting to the heart of it, but the analogy I like is
making a movie, the final result is very open-ended and coordinating the
activity of getting a result very complex, also, whether the end result
is a success is very much dependant on intimate knowledge of the humans
who will view (use) the outcome.

I think that a better analogy is a large construction project like an office building or a large bridge.  They often run over budget and schedule, and often develop unforeseen problems.  Some of them are almost exactly like previous ones, and some have many new elements. During construction, unexpected problems arise, and once completed, usage patterns may turn out to be quite different from those anticipated.  Many of the implementation details are routine and implemented by tradesmen who don't know much about the overall architecture.

I've operated with that idea for many years, but I'm coming to believe it's actively destructive because it leads to pure waterfall thinking: design, architect, engineer, build.  Where is there a place for an iterative design, build, test cycle in building construction?

-Mike

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l....org
subscribe: xml-dev-subscribe@l....org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php