This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies.



Some critiques of the Semat initiative

Given the ambition of the Semat project it would be surprising if it did not cause some controversy. Alistair Cockburn wrote a long critique at Martin Fowler, at, echoes Cockburn and states that the effort is “fundamentally doomed”.

The issues are complex and we welcome controversy. We regret, however, the strident tone of these comments and their authors’ decision to criticize from the outside rather than helping with Semat’s mission of improving software engineering. This decision is for a large part based on rather unconvincing generalities. For example Fowler’s argument is that “I spent a fair bit of time in the 80’s and 90’s mucking around with this idea. In the end I decided that it was too hard and of limited value.” It is good to know that Fowler gave some thought to the problems of software engineering twenty years ago and gave up, but others might be forgiven for not finding this a good enough reason for the rest of the world to stop looking for solutions.

Fowler writes: “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.”  This is a misreading. The Semat kernel is not at the “meta” level; it is a concrete kernel of practices and patterns. The kernel is small, and includes universal elements relevant to all development projects.  It will be used to describe methods.

Cockburn’s critique exhibits a problem that we had foreseen and explicitly tried to forestall: the prima donna phenomenon. In setting up Semat we have contacted thought leaders in software methodology (Cockburn and Fowler included) and asked them to accept that each has a piece of the truth but none has the entire truth. We understand that this is difficult to accept (none of us is particularly modest either), but that accepting to work together regardless of guru status is essential to progress. Cockburn’s main argument is the eight years of carefully constructed literature including his own book, and that his 2002 doctoral dissertation pointed out that ”methodologies will inevitably increase in number, not decrease”. Much as we enjoy Cockburn’s contributions, they are neither the only word nor the last word.

Nowhere do the Semat documents suggest that Semat would result in fewer methods.  The Call for Action’s mention of the “huge number of methods and method variants“; Alistair cites this, but ignores the following comment:  “with differences little understood and artificially magnified.”  The problem is not the large number of methods, but their monolithic nature and the difficulty of comparing and combining them The Semat initiative should in fact make it easier to create new methods out of a smaller number of clearly defined practices.

Cockburn’s complaint also embodies a strangely thin-skinned reaction to suggestions that previous ideas, in particular Agile ideas, may need further refinement. Cockburn objects to our comment on the Agile manifesto, which stated that:

“… the elegantly written foundational document of the [Agile] approach is a “manifesto”, long on emotional appeals in the first person plural and short on facts. This style may be effective to capture attention, but as ideas mature it should yield to more traditional (even if also more boring) forms of argumentation.” (From an article by Ivar Jacobson and Bertrand Meyer)

He states that “The authors once again use precisely the polemical language they decry”. This is a bizarre criticism: first we don’t object to “polemical” language (discussion is a normal part of progress in science and technology), only to assertions that are not backed by facts and theory. Second, the article from which this is extracted was published long before the Semat documents and the first Semat meeting, so it is not like he discovered it after attending the meeting. But third and most importantly, our cited extract is quite laudatory of the Agile Manifesto; it simply points out that manifestos are not enough (a comment that also applies to the Semat Call for Action). It is one of the fundamental premises of the Semat effort that there are no sacred cows: we want to get the best of all existing ideas, agile included, and understand their limitations as well. We fear that Cockburn’s reaction shows a lack of willingness to have any aspect whatsoever of agile methods questioned in any way. That is not justifiable: everyone’s ideas, including ours, Cockburn’s and Fowler’s, should be assessed at face value.

Cockburn is also critical of the Zurich meeting. He complains that no agenda was presented.  Of course the meeting had an agenda; If he had read that agenda, the Call for Action and the vision statement, he would have known the goals and principles of the Semat initiative before he decided to come.  Moreover, He omits one of the main difficulties that this meeting (altogether very successful) encountered. The cause of that difficulty was Cockburn’s own decision, unannounced, to comment on the discussions in real time on Twitter; many of the comments were sharply critical of other participants. One of these participants suddenly found out and was upset at what he viewed as a betrayal of trust. A discussion ensued, moderated by us (we maintained a neutral view); it led first to a decision to allow tweeting and soon thereafter to the reverse decision, as a majority felt the tweeting compromised the quality and integrity of the discussions. This was a side issue, and was taken care of, but it did divert the meeting from its focus and cause tempers to rise for a while.

Cockburn states that the “state of [the research literature] more indicates that we don’t yet understand what is happening on software projects”. This is greatly exaggerated; of course we as a community do not understand everything — if we did, there would be no need for Semat — but a vast amount of literature, including both process-oriented (CMMI etc.), object-oriented and agile sheds considerable light on the reality of software development. The attitude that we don’t understand anything anyway is good for gurus (just as ignorance of medicine is good for witch doctors), but Semat takes a different view: that we know quite a bit already, albeit in a messy and often inconsistent way; that we must organize and classify this knowledge; that we must assess every idea, existing or new, through objective criteria, without fear or favor; and that we must apply our best efforts to solve the remaining open problems. Proponents of agile methods have a major role to play in this process.

— Ivar, Bertrand, Richard

No hay ningún comentario aún. Sea usted el primero.