SEMAT, Mastery, and Human Factors

In my links-to-links-to-links exploration, which I think of as fractal (but had a debate with PhD-types who felt that this is not true – but more about that in another thread), I came across this discussion of the “Software Engineering Method and Theory initiative” (SEMAT).

It seems what they are up to (again) is creating a meta-process for designing/developing software.  Digging into it, I found their manifesto (you have to scroll a little on their page to see it in context):

Call for Action

Software engineering is gravely hampered today by immature practices. Specific problems include:

  • The prevalence of fads more typical of fashion industry than of an engineering discipline.
  • The lack of a sound, widely accepted theoretical basis.
  • The huge number of methods and method variants, with differences little understood and artificially magnified.
  • The lack of credible experimental evaluation and validation.
  • The split between industry practice and academic research.

We support a process to refound software engineering based on a solid theory, proven principles and best practices that:

  • Include a kernel of widely-agreed elements, extensible for specific uses
  • Addresses both technology and people issues
  • Are supported by industry, academia, researchers and users
  • Support extension in the face of changing requirements and technology

People involved in creating this are great thinkers – out of laziness I am paraphrasing below from Wikipedia:

  • Ivar Jacobson: a Swedish computer scientist, known as major contributor to UML, Objectory, RUP and aspect-oriented software development.  (He claims to be the “Father of UML” on Twitter…)
  • Bertrand Meyer: an early proponent of Object-Oriented Programing and a proponent of (gasp) of the ideal of simple, elegant and user-friendly computer languages (I thought Basic was pretty simple and elegant, but I’m not a Master).
  • Richard Soley: lead the development of a standard called the Common Object Request Broker Architecture (CORBA) which enables software components written in multiple computer languages and running on multiple computers to work together (i.e., it supports multiple platforms).

Some people I admire a lot have also signed:

  • Ken Schwaber: co-codifier of Scrum with Jeff Sutherland (don’t see Jeff on the signatory list)
  • Ed Yourdon: writer of Death March project management book.

What I found interesting is even in the language that they use in their communications is super-formal.  And it made me think if the language itself is not human-friendly, then a sense of rigidity sets in. A sense of “Well, we’re the experts, so don’t question us,” sets in.  What we seem to be up to here, we beings, is creating strong walls for reality to exist within. We’re denying the fractal nature of experience.

I found these critiques from Alistair Cockburn, Martin Fowler, and Kelly French.

http://alistair.cockburn.us/A+Detailed+Critique+of+the+SEMAT+Initiative

Dr. Cockburn observes the effort is…

intended to generate support through appeal-to-authority, hype, and ambition

Later in his article he observes that ideas are not considered if not “widely accepted.”  This I think is at the heart of being closed-minded in some ways.  But it is a contradiction!  If thinking and writing are not peer-reviewed, how can they ever become “widely-accepted?”  And – is “widely accepted” such a good thing anyway? Seems like all those “widely-accepted” ideas get us into whole deep pots of hot water.  (Like – wasn’t Mubarak of Egypt “widely accepted?”)

http://codewright.blogspot.com/2010/04/martin-fowler-alistair-cockburn-and.html

Kelly French talks about how we want people to “fly right.” It’s such a great short post, I am tempted to copy the whole thing here – but will satisfy myself with:

While Extreme Programming hasn’t become the standard development model, that doesn’t mean it failed.  When the history of Software Development is written, XP will be given credit for re-introducing the most important factor; not tools nor process, but people.

For later – for me to handle in another post – she talks about the “dark side” of people. (What I’ll think about later is the dark side, “human nature?”, grasping, ignorance, and is there any “bad,” really?)

http://martinfowler.com/bliki/Semat.html

In his very short post, published just to explain why he didn’t get involved in SEMAT, Martin Fowler says:

I got the distinct impression that the central thrust of the initiative is to create a software meta-method-kernel – essentially a set of common process elements for software developments that you can rigorously compose into a method for your own project.

And this leads me back to the concept (and desire) to be peer-reviewed.  “Peer” reviewed.  Who gets to be a “peer?”  Who is an expert?  I say in another thread that it is a Master and someone who has “done” something. People who have shown the discipline and wherewithal to have spent time doing the homework and who, therefore, should be respected for their knowledge and opinions.  Otherwise, like artists who worked in the 80s rediscovering this little thing called “perspective” we just end up repeating thought patterns that these experts have already been down.

Or is this true?  Again, the student’s questions should be viewed with fresh eyes by the Master.  Was the Master really right? (correct?) The data seems to support the idea.  Could the data react differently in different circumstances? With the causes and conditions changed?  When we include the human factor?

Advertisements

One Response to “SEMAT, Mastery, and Human Factors”

  1. Kelly French Says:

    First, thank you for the kind words.
    If you liked my post about Martin Fowler’s reaction to SEMAT, you might enjoy this other post of mine about the connection between Extreme Programming and people (http://codewright.blogspot.com/2009/11/extreme-programming-is-people.html) and I’d also encourage you to read Cockburn’s more detailed piece on *WHY* attempts to generalize processes between groups or teams fail to account for the most important factor, people (http://alistair.cockburn.us/Characterizing%20people%20as%20non-linear,%20first-order%20components%20in%20software%20development). Cockburn’s results should be held up there alongside DeMarco’s Peopleware. Also, I’d be remiss if I didn’t suggest Weinberg’s classic ‘The Psychology of Computer Programming’.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s


%d bloggers like this: