Kurt's Blog

September 2, 2009

Review of “Principles of Software Engineering Management”

Filed under: Software Development — Kurt Häusler @ 6:37 am


I recently finished reading Tom Gilb’s ‘Principles of Software Engineering Management’, a book, published in 1988, that I started reading a few months ago for a uni assignment. At the time I was not too impressed. A lot of what is written in the book seemed to take software development in opposite directions to what I have come to appreciate as almost being best practices. Development teams today tend to be reducing the distance to the customer and being formed by tearing down the walls between analysts, designers, developers and testers, and working together to deliver functionality that satisfies customer requirements with minimal waste. The book however defines the following roles: Infotect, Softect, Software engineer, Specialist software engineer, Softcrafter, Moderator and Inspector. According to the book, I, as a “Softcrafter” presumably, would be “a software craftsperson who constructs software according to the design of others.”

But hold on, isn’t that what the compiler does? I am however pleasantly surprised to see the term “craftsperson” used. I suppose I could qualify as a Software Engineer who: “translates required software system attributes into appropriate designs capable of meeting those requirements”. I assume those designs are documentation rather than source code, or what would the softcrafter do?

Much of the book introduces Gilb’s Evolutionary Delivery Method, or Evo, which develops software increments or iterations just like todays agile and lean teams. In this respect Gilb was one of the first to present such an idea. (More information on the history of Iterative and Incremental Development can be read about in this excellent PDF.)

Quality attribute specifications are another worthy aspect of the book. Most of the time requirements (regardless of methodology) are either/or type things. A feature is either present or not. Gilb advocates an additional set of requirement specifications that are expressed in quantifiable measures. They express how well a solution satisfies a requirement rather than simply whether it does or not, and can be tracked over time to see how future changes impact on previously completed solutions. I find this concept could be a powerful tool for setting constraints on both external and internal quality attributes like technical debt levels, that so often get neglected in the relentless pursuit at delivering customer value today (at the expense of delivering it in six months.) Another good article that explores this concept further is Ryan Shriver’s Measureable Value with Agile

Inspection is another interesting topic. The book borrows mostly from the work of Michael Fagan at IBM. I do find it to be rather heavily focused on inspecting for errors in documentation though; errors in the software itself are briefly mentioned as an afterthought. I think in the meantime we have come to realize that documentation is always going to be a vaguer, less correct, lagging version of the software itself, and by realizing this we can minimize waste by focusing on software as design, treating documentation as a temporary guide rather than spending a lot of effort keeping it definitive and up to date when it often never gets read, and by reducing the distance between the customer and the developers, and therefore the need for some much documentation in the first place.

I am however inspired by the use of inspection as a tool for identifying and quantifying internal software quality attributes that can’t be measured easily (yet) with an automated tool such as antipatterns, code smells and technical debt, as well as a learning tool, to help get new maintainers up to speed on large code bases.

Throughout the book, and in the entire last section, one can find all sorts of case studies, tips, and references to other literature.

Overall, I find it worth reading. However don’t forget it was published in 1988, so parts of it may seem old fashioned, or contrary to what people now understand works well in software development, and have been further, and arguably better explored by others in the meantime, particularly in the agile and lean communities. However, theres a lot here, such as quality attribute specifications, that are still today under-discussed, and in those areas, Gilb’s book remains not only relevant but authoritative.

I have started reading another of Gilb’s books, “Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage”. It describes itself more as a handbook, so I am still unsure if I will continue reading it cover to cover, or wait until I my employer implements planguage and I can use it as a reference.



  1. Kurt,

    good to see you finished the book, and have started CE, which pulls together his ideas since the 1988 book. You’ll find the second book is more formal, and a not as ‘fun’ a read as the older one. The newer one is still a useful read and a more useful reference book, especially if as you imply, your employer is going down this route. Tie these two together with Shriver’s piece and you’ll go a long ways to pulling together projects of which your clients are well-satisfied.

    Comment by Bruce — September 5, 2009 @ 9:15 pm

  2. I like this review!
    PoSEM is in 20th printing, so someone out there respects it!
    CE book is tougher, but even more deep! So do you want easy to read or powerful?
    Is your employer considering Planguage?
    Maybe you have to make it happen.
    Rolf Götz is your German friend-of-Gilb

    Comment by TOM GILB — September 9, 2009 @ 9:56 pm

RSS feed for comments on this post. TrackBack URI

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 )

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

Create a free website or blog at WordPress.com.

%d bloggers like this: