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.