Tom Gilb - Q1

Tom Gilb is one of my Agile heroes.  He's been doing and teach agile for a looooong time, but many Agile newbies may not recognise his way as the agile way.

Q1: Hi Tom. I started University in 1988 ... which is the same year that your classic book "Prinicples of Software Engineering Management" was published.  According to my calculations that means your book has now been around for 20 years.  I only came across it a few years ago but it has influenced my thinking more than any other "software development" book.  I know of several of the better known Agile guru's who say similar things.  Can you tell us a little (or a lot) about what lead you to write the book and where your ideas came from?

Yes PoSEM is now in 20th Printing - I was asked by my publisher to make an 'evergreen' - and apparently it is!

 

I like to think my 2005 book, Competitive Engineering (CE), is a worthy successor. It treats the same subjects, but more deeply. It is not such an easy read, but we have other books to serve that purpose including Kai Gilb' s "Evo" book          http://www.gilb.com/community/tiki-download_file.php?fileId=27

It was important to me that the CE, which officially defines Planguage, was reasonably rigorous. Time will tell, but it is in Second Printing and is well reviewed, so there is hope for the future!

What led me to write the book?

Well, let me remind you of the book's predecessors:

1976 Software Metrics (coining the term, and the official foundation for IBMs CMM Level 4   [I don't take all blame for CMM!]). In USA 1977.]}

1974-5 Reliable EDP Application Design, and Data Engineering (neither in USA, but both in Sweden and UK).

These were the real beginnings - PoSEM was second generation!

You might say the centre of my technical universe is 'quality quantification'.

The driver there is -  the Lord.

 

 

OK!       Lord .....   Kelvin.

 

 

About 1965 the following appeared in a Norwegian newspaper: (I joined IBM Norway 1958, at 17)

"I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it;

but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind;..."

http://zapatopi.net/kelvin/quotes.html,  

 

 

 

That got me thinking about whether we could quantify critical quality properties like portability and security. I had no internet to search, and my international personal network from conferences was a good Who's Who (Dijkstra, Langefors, Naur, Nygård, Dahl)  - so I tried common sense and invented and published some ideas on how to quantify them. I also quickly found out that they worked in practice.

 

As I worked as a consultant, I got challenged with extending the vocabulary, for example extensive work with ICL UK in the early 1980's led to defining Adaptability, and from 1980 with IBM led to defining Usability. As late at 1995 at Ericsson (Erieye airplane) we extended Usability with Intuitiveness and Intelligibility. And these and others became stable, and became patterns for tailoring local variations. More recently my friend Lawrence Day of Boeing pointed out to me that my method is in the Bible, 1st Corinthians, defining Love by decomposition into several quantifiable factors ('endureth long'). And I realized that Rene Descartes was on to 'my' method centuries ago.

 

Another early inspiration was a UK Professor Christopher Strachey, Oxford University Computing Labs, in the 1969 NATO Science Council "Software Engineering Techniques"  Proceedings page 65)  http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF

 Christopher Strachey (Oxford) : “Computing science has been under some attack on the grounds that it isn’t software engineering. I propose to attack it on different grounds. I think we should seriously ask ourselves the question: is computing science? 

Recently I did a small survey as to whether computing is suitable as an undergraduate subject in an English university. I did this by grading all the topics I could think of under the headings of relevance and state of development. The premise is that it is clearly wrong to teach undergraduates the state of the art; one should teach them  things which will still be valid in 20 years time: the fundamental concepts and underlying principles. Anything else is dishonest.

The gradings for relevance ran from “clearly relevant and essential” to “part of another subject” (like numerical analysis) and those for state of development from “well developed with theorems, laws and text books” to “a fruitful field for research”. Note, incidentally, the importance of text books. They are designed to be taught from; they are quite different from treatises and even further from research papers. Now, it turned out that all those subjects which score highly for relevance score very low on state of development and vice versa. 

Until we have a sufficient body of topics which are important, relevant and well developed we cannot call the subject a “science”. I am quite convinced that in fact computing will become a very important science. But at the moment we are in a very primitive state of development; we don’t know the basic principles yet and we

must learn them first. If universities spend their time teaching the state of the art, they will not discover these principles and that, surely, is what academics should be doing. 

I do not for a moment underestimate the importance of the state of the art in engineering. Clearly it is essential and furthermore from engineering practice we must get our experience and material from which we develop theory. But, before teaching students we must get our basic principles right." [Strachey 1969]

Well, I found he was right. There were not many principles published or available (Langefors (Theoretical Analysis of Information Systems) and Naur had a handful).

 

So, I drafted a number of principles, based on my 'engineering experience'. About 124 principles were published in PoSEM (1988) and at least 100 Principles in CE (2005).

I like to think they "still be valid in 20 years time". In fact we can now test the 1988 Principles - would anyone like to argue they are not valid today?

 

My own arguments for  subjects  that will "still be valid in 20 years time". is in my paper Undergraduate basics http://www.gilb.com/community/tiki-download_file.php?fileId=98

The paper argues that principles, concepts and measures are primary tools to learn about.

 

A few academics have understood this, but not many, as far as I can see. I also see the consequent helplessness and waste in software projects that seem to me to be the consequence of the lack of fundamentals. We cannot seem to get decent quantified requirements at the top level for large projects - ever. We never seem to get past step One.