O X F O R D   S O F T W A R E   E N G I N E E R I N G
C o n s u l t I n g   S o f t w a r e   E n g I n e e r s


 What’s New    PODS    Products & Services    Library    Presentations & Papers    Related Sites    Events     History    Clients 




These books and reports may prove useful for software developers, managers and those involved in understanding, improving or measuring software or software development practice. We are continually adding more to the list. If you have a particular book you would like listed here please email us at shelley@osel.netkonect.co.uk.








61. Applied Software Measurement: Global Analysis of Productivity and Quality, by Capers Jones, pub McGraw Hill, 2008, ISBN 0071502440   I’m not sure how I missed this. Applied Software Measurement has been around for twenty years and is now in its third edition. I was pointed to it recently have just read it for the first time. It is very wide ranging. Unlike many software measurement books that reflect their origins this book takes a wide ranging view across industry sectors, pointing out their characteristics, strengths and foibles in a way not covered elsewhere. I thought of a few topics of particular interest, looked them up in the index and was pointed to useful discussions and techniques. The book is packed with clear thinking, good ideas and useful checklists (like CJ’s ‘Assessment and Control of Software Risks’, see 54 below).  It does have a distinguishing characteristic – function points are a major topic. They are used here to provide a universal measure to enable comparisons, which is perhaps a clue to why the book is not better known. FPs tend to be specialist measures, not widely used beyond the (rather insular) FP community and perhaps this is the block to a wider readership.  Most of the software development community do not know about or use function points.  Capers Jones is a passionate advocate of FPs and this book shows why:  how they have been used to make illuminating, useful, and valuable comparisons.  Whether or not you know about or like function points this book is essential reading for anyone wanting to better understand software development and software measurement. CCS December 2011








60. CMU/SEI-96-HB-002 Goal Driven Software Measurement, by Robert E. Park, Wolfhart B. Goethert and William A. Florac, pub SEI, 1996  Re-reading this report while developing a software measurement training course and attempting to produce a practical software measurement handbook reminded me how good this report is.  The SEI used to produce many excellent reports (their SEPG guide is another excellent one) and this guide to Goal Driven Software Measurement is very, very good.  The heart of the report is a guide to a GQM type approach to developing measures – with the authors’ modification, the insertion of an (I) into GQM. The GQM part of the report is good, in particular the guidance on how to define a measure by constructing a checklist to capture data collection ‘counting rules’. This seems to be the most practical and specific software measurement definition method, simplified from Park’s rather overcooked description of the method in the 1992 guide to counting lines of code. As well as GQM guidelines and the excellent and crucial definition method the guide contains a wealth of excellent advice and guidance on how to measure wisely and well.  The guide is freely available from the SEI as a downloadable pdf. If you are involved in software measurement download a copy  - and find out what the I in GQ(I)M is for. CCS August 2010.








59. Making Process Improvement Work, by Neil S. Potter and Mary E. Sakry, pub Addison Wesley, 2002, ISBN-13 978-0201-77577-8, ISBN-10 0-21-77577-8/    This is one of the best books on software process improvement.  The many endorsements are an accurate reflection of its quality. It is a very clear and concise guide (only three chapters) on how to improve software development practice. It should be read by anyone involved with process improvement - especially if they are using CMMI or similar process models. Potter and Sakry offer guidance on how to focus on real improvement, rather than getting seduced by model compliance. There are plenty of useful techniques and tools for directing and managing SPI work, measuring progress in terms of business benefits and lots of good advice too.








58. Creating a Software Engineering Culture, by Karl E. Wiegers, pub Dorset House, 1996, ISBN 0-932633-33-1      This book was acquired as preparation for Tom Gilb’s ‘Changing Culture’ seminar earlier this year.  As you would expect from Karl Wiegers this is a sound, well considered and lucid book, based largely, I suspect, on the author’s own experience. It describes the fundamentals of process improvement and provides many hints and tips on what to do to encourage good practice. Just as useful, it describes what will de-rail attempts to improve.  The author presumes that the objective of process improvement, reflected in the title, is to develop a software engineering culture. It is worth bearing in mind that this is now a software development niche. Software development is undertaken in an enormous variety of contexts and cultures and software development, performed by engineering oriented developers (making embedded systems, avionics and the like) is only one of these.  As such some of the techniques and methods proposed may cause difficulties. Inspections and SQA spring to mind. Never the less as a guide for managing change and encouraging good practice this is a very useful (if slightly dated) book. CCS July 2009








57. A variety of measurement books: This collection, together with those others listed below, should equip anyone to understand, and make a reasonable job of measuring software or software development processes. These don’t deal with software measurement specifically, but I increasingly believe that thinking in terms of specifically ‘software measurement’ is unhelpful, ‘ghettoizing’ the subject and closing off necessary ideas dealt with so well in other areas.


The first, and most important, is Tukey’s Exploratory Data Analysis, by John W. Tukey, pub. Addison Wesley, 1977, ISBN 0-201-07616-0. This is a classic text, idiosyncratic but easy to read, describing deceptively simple techniques to explore and extract information from data. These techniques are ideally suited to software engineering data, but they are little known and rarely encountered in the software world. Its methods can be used to establish the character of unusual or ‘messy’ data, re-express it in meaningful and useful ways. An important book, neglected by the software measurement community to its cost. Copies can still be acquired second hand, but they are expensive.


The second was recommended at the last of Tom Gilb’s seminars. Everyone had apparently heard of this apart from me. It is The Logic of Failure: Recognizing and avoiding error in complex situations, by Dietrich Dorner, pub. Basic Books, 1996, ISBN-13: 978-0-201-47948-5, ISBN-10: 0-201-47948-6.   It describes how difficult it is to manage complex situations over time, even with measurement data.  This failure is then analysed and the, apparently simple, steps needed to fix it described. It is easy to be amused by the failures described in this book and assume that we would do better. The value of this book is in recognizing how we make the same mistakes ourselves, and then take the steps prescribed ourselves.


Next is Taleb’s The Black Swan: The impact of the highly improbable, by Nassim Nicholas Taleb, pub. Penguin, 2007, ISBN 978-0-1410-3459-1. This is the follow up to his earlier ‘Fooled by Randomness’ (also worth reading) This highly, and deliberately?, discursive book looks at the nature of uncertainty and the attempts to predict the unpredictable. Taleb clearly has an agenda and lays into statistical ‘gurus’, including Nobel prize winners, with a vengeance. He also introduces his statistical and philosophical heros. The misapplication of conventional ‘Gaussian‘ statistical models in ‘Extremistan’ – most of the world, where data ‘scales’ -  is taken to task. (Mediocristan is the territory where Gaussian and other parametric statistical tools do work.)  Conventional statistics get a rough ride, unfairly so, as the author acknowledges, but this is understandable seeing how it is so often so badly used. The final sections of the book deal with some of the statistics that have talked about earlier and presents some truly startling statistical facts that reinforce his views about the nature of data in the real world. Some approaches and tactics to deal with ‘unknown unknowns’ are described, and there are thought provoking ideas, but a lot of distractions too. Not an easy read, sometimes the language is unclear and requires rereading several times to make clear what is meant, and an occasionally irritating style, but worth it.


Finally there is Douglas Hubbard’s How to Measure Anything: Finding the value of intangibles in business, by Douglas W. Hubbard, pub Wiley, 2007, ISBN 978-0-470-11012-6.  This is the polar opposite of Taleb’s book. (It would be interesting to see Hubbard and Taleb compare ideas.) Hubbard’s book is cast as a ‘business book’, but is in fact very good. It looks at the difficulties people have measuring. The c – o – m model will be particularly useful; many efforts at measurement fail because people just do not believe it can be done, or think it is some sort of technical magic. The book then looks at measurement from a classical statistical perspective, dealing with the need for appropriate levels of accuracy and precision, and the need for sufficient data, which can be remarkably low. Estimation ‘calibration’, statistical modelling (in particular Monte Carlo methods, which seem to be the coming thing) and the need to experiment and develop ideas, models and measures are presented clearly. There is also an excellent section on Bayesian approaches, something often presumed impenetrable except for the statistical priesthood. There are discussions about the softer aspects of measurement and the book is backed by some tools that can be downloaded from the website. If there is a criticism it is that the layout of some of the technical sections could be clearer. Discussion of formulas or expressions is embedded in text. I found this difficult to follow. A more traditional layout, with lots of white space would be preferred. CCS November 2008








56. Statistical Quality Control Handbook, Western Electric Company, 1956.
This is a working handbook prepared for Western Electric people to enable them to use statistical quality control. It is an exceptional book.  It clearly and persuasively describes many widely applicable, practical, powerful and elegant statistical techniques to solve manufacturing and quality problems. Its importance to software developers is as a model of engineering practice. The software development community (and in particular the SEI) is searching for similar statistical approaches to assist in the management and control of quality for software. This book should be studied for its wisdom and clarity, and used to set the standard for a similar text for software engineers. If quantitative approaches of similar practicality and power can be developed for the peculiar challenges software presents, without slavish imitation of manufacturing SQC techniques, then software development may have a claim to being software engineering. CCS June 2008








55. Dreaming in Code, by Scott Rosenberg, pub. Three Rivers Press, 2007, ISBN 978-1-4000-8247-6.
Very entertaining story of the development of ‘Chandler’, an OS Outlook/Agenda/PIM product by a team set up by Mitch Kapor. Developers will recognize many of the things that make software development what it is - the author is a keen observer of techies doing techy things. Having said that I got the very distinct impression that the team was not one I’d want to get too close to – way too many big names, way too much navel gazing and high concepts, no real deadlines either. I found myself wanting to tell them to just get on with it (I must be turning into a manager). There’s some interesting discussion on how software is developed, taking in CMM through to the agile manifesto, and by who – artists or engineers? As it says on the cover – ‘successor to The Soul of a New Machine’ – good read. CCS April 2008








54. Assessment and Control of Software Risks, by T Capers Jones, pub. Yourdon Press (Prentice Hall), 1994, ISBN 0-13-741406-4.
This is a wide ranging, intelligent and occasionally provocative review of the ills of software development. It takes its structure from the 'Control of Communicable Diseases in Man'. This works well - easy to navigate, thoughtful analysis, often backed up with data.

This book should probably be considered as obsolescent now, but it has so much useful information and cues for valuable checklists I believe it's a classic. CCS April 2008








53. CMMI Second Edition: Guidelines for Process Integration and Product Improvement by Mary Beth Chrissis, Mike Konrad and Sandy Shrum, 2007, Addison Wesley, ISBN 0321279670.
The revised reference for CMMI has had the structure simplified and some of the process areas merged, in particular IPPD is de-emphasised, and ISM, IT and OEI deleted. (see 32 below). Common features have now disappeared, which is a pity, and the continuous representation has all but disappeared too, another pity. CMMI is now quite remote from software development, TS and PI say little of interest and VER is too vague. It concentrates on project and process management. This book still contains a lot of wisdom, CMMI and its predecessor CMM, knew where to borrow from, but increasingly this wisdom turns up in odd places: in the introductory section, the hints and tips in the margins, and odd sentences scattered throughout the text. None of this really matters now: this is the standard text used by the assessment industry and all those chasing MLs. CCS April 2008








52. Engineering and the Mind’s Eye, by Eugene S. Ferguson, pub. MIT Press, 1992, ISBN 0-262-06147-3.
This book was recommended by Michael Jackson at a recent BCS FACS meeting. It isn’t directly concerned with software engineering, but the engineering process and the visualization of engineering artefacts. It gives fascinating insights into the design process and, since software development is a design process, software development, and the way software developers communicate, and fail to communicate. A small book stuffed with ideas. CCS June 2007








51. Agile Estimating and Planning, by Mike Cohn, pub. Prentice Hall, 2006, ISBN 0-13-147941-5.
The list of citations for this book on the inside cover gives an indication of its value. It’s unusually readable, and describes many of the situations and issues encountered by software developers when involved in planning or estimating, but that are not dealt with in most books on the subject. Mike Cohn consistently gives good advice and describes useful techniques. Don’t worry about this being about agile estimation and planning most of the techniques can be adapted for other environments. The only criticism of this excellent book is it’s too wordy. It could have been half the length. Never the less if you are involved in any form of software estimation or planning get this book – an instant classic. CCS Feb 2007








50. Software For Your Head: Core Protocols for Creating and Maintaining Shared Vision, by Jim and Michele McCarthy, pub. Addison Wesley, 2002, ISBN 0-201-60456-6.
The authors have set out to identify those things that make teams take off and really perform, and the things that stop them performing. This has been achieved at the McCarthys’ ‘boot camp’ by creating teams, making them perform, and analysing their performance. The results are set of patterns that can be learned and used, and corresponding antipatterns to be recognized and avoided or eliminated. The results presented in this book are impressive, but unsettling. The patterns may well be uncomfortable or embarrassing to introduce and adopt, requiring team members to act with more integrity and candour than is usual, and many of the antipatterns describe behaviour that most team members will recognize in themselves. The McCarthys don’t pull their punches either. No concessions are made to appeals the ‘real world’: to build high performing teams delivering excellent intellectual property team members must understand and value themselves, visibly and openly commit to themselves, the team and the team’s vision, and recognize and eliminate the second rate, faux pragmatism and the bogus. The prize is the pleasure and satisfaction many will know from working on high performance teams, and the ‘can do’ belief and ability of the team to do almost anything. This book is not an easy read, it will make you aware of your own, and your team’s limitations, is perhaps longer that it needs to be and the writing can be verbose, and occasionally pompous, but it is filled with wisdom and insights. And it does present very clear models of behaviour rather than the usual rather vague advice and mumbo jumbo. This may be an important book, the ideas certainly are. CCS July 2006








49. Test Process Improvement: A practical step-by-step guide to structured testing, Tim Koomen and Martin Pol, pub. Addison Wesley, 1999, ISBN 0-201-59624-5.
TPI is a model of testing practice based loosely along CMM and SPICE lines, but scoped to software quality control. It uses maturity/capability type ideas to describe increasingly more sophisticated testing practice and in doing so enables testers to gauge their testing practice and provides guidance on where to focus their efforts to improve testing. Like CMM and SPICE, TPI can be mined for good ideas and good practice or provide a roadmap for strategies to improve test effectiveness. The book not too thick - about 200 pages - and is reasonably easy to read and understand, although the text appears to have suffered a little from translation from the Dutch. The model itself appears reasonable but does not have the rigour or accountability of CMM. There are some ambiguities and inconsistencies in the model but these do not seem to have any significant impact on its usefulness (in fact this ‘cheap and cheerful’ approach is a refreshing change from the increasingly over-engineered, over-produced CMMI). If there are any criticisms it is the treatment of technical reviews which is not very clear, and of process improvement, actually making the changes to testing practice itself, which is not altogether convincing or useful, but these are minor points. As guide for structured and practical improvements to testing practice this is a useful resource. CCS January 2006








48. Measuring and Managing Performance in Organizations, by Robert D. Austin, pub. Dorset House, 1996, ISBN 0-932633-36-6.
This book explores measurement dysfunction – why it doesn’t work as expected. And, usefully, takes the measurement of software development as its focus because it encapsulates so many of the issues of performance measurement. Austin develops a model for reasoning about measurement and uses this to look at performance measurement’s fragility, and the motivations of the measured, the measurers and the experts. It describes how performance measurement is treated in different cultures and suggests where the value of measurement really lays. This book will disturb and provoke those involved in software measurement, especially consultants. It is all the more disturbing because it convincingly reveals the reasons behind so many of the software measurement problems we encounter. CCS July 2005








47. CMMI Assessments: Motivating Positive Change, by Marilyn Bush and Donna Dunaway, pub. Addison Wesley, 2005, ISBN 0-321-17935-8.
The SEI’s reference text for Assessments. A comprehensive guide to assessments describing the what, why and how of assessments by two of the people that helped develop the CMM and the assessment process. Essential if you are planning an assessment and want to get the best from it. Provide each of your assessment team members with a copy. CCS June 2005








46. What is this thing called Theory of Constraints and how should it be implemented? by Eliahu M. Goldratt, pub. North River Press, 1990, ISBN 0884270858.
Why didn’t someone tell me about this before? A thin ‘management’ style book on process improvement by the originator of the Theory of Constraints (TOC) and author of  ‘The Goal’, a process improvement novel - yes really. It describes how to identify real limitations on systems, and how to control and use them. It has two parts: part one describes the theory of constraints; part two describes how to make changes. CCS April 2005








Some background reading for process engineers, and other involved in managing change:

45. How to Win Friends and Influence People, by Dale Carnegie, pub. Vermillion, ISBN 0-7493-0784-6.

A dated and quaint style now, but the guidance is as true as ever. Look through the cliché title; it really does describe how to influence people.

44. The Prince, by Niccolo Macheavelli, pub. Penguin, ISBN 0-14-044107-7

Describes how things are, rather than how we’d like them to be. The section on changing the status quo is still true.








43. Measurement Theory and Practice: The World Through Quantification, by David J. Hand, pub. Arnold, 2004, ISBN 0-340-67783-X.
This book will be of interest to software engineers wanting to understand measurement and get it right. It takes up where Fenton leaves off (See 12 below). There is a history of the development of measurement, a comprehensive description of the nature of measurement itself; its theoretical foundations, pervasiveness  - and consequential invisibility. The nature of measurement in different disciplines is discussed – in psychology, medicine, physical sciences, economics... and briefly software. The difficulties and controversies and limitations of measurement are also revealingly discussed; showing that the problems encountered measuring in software engineering are not unique, and many solutions have been found in other disciplines, but that serious work is required to overcome them. This book is densely written, with some maths and will require serious study, but for those committed to software measurement it is a compelling and illuminating read. CCS April 2005








42. Facts and Fallacies of Software Engineering, by Robert L. Glass, pub. Addison Wesley, 2003, ISBN 0321117425.
Robert Glass presents 55 facts and 5 + 5 fallacies of software engineering. Actually they’re not facts; they’re very well founded opinions backed up with references and data. And that’s the important signal sent by this book. Software engineering is not developing as a discipline because hard won knowledge is lost or ignored as soon as it’s gained. We need books like this to encapsulate some of the eternal verities that tend to be forgotten in the enthusiasm for the latest nostrum. Each fact is presented as a one liner – “Fact 7 – Software developers talk a lot about tools. They evaluate quite a few, buy a fair number and use practically none.” And then this is developed in a page or two of discussion. The controversies that these statements are likely to provoke are outlined and sources and references provided. The facts and fallacies will be recognized by most experienced software engineers and managers, but somehow seem to be overlooked in day to day work. Several times the absurdity of software engineering practice, as practiced, is highlighted, and our inability to break out of these destructive habits discussed.  The book is deliberately modelled on Alan Davis’s ‘201 Principles of Software Development’ – see 31 below, and Alan Davis provides the forward. Each of the facts or fallacies is covered in a few pages, easy to read and absorb. So what is the book for? It’s a map of the software engineering terrain showing where some of the pitfalls are, but it doesn’t contain methods or techniques that can be extracted and used. It is more of the nature of ‘hints and tips’ for software engineers.  Perhaps one use would be to extract the facts as sets of checklist items to be used at key points during software development or as concise arguments to be deployed when some sub optimal path is proposed. It should be included in software engineering student’s reading lists. CCS March 2005








41. Lean Software Development: An Agile Toolkit, by Mary & Tom Poppendieck, pub. Addison Wesley, 2003, ISBN 0-321-15078-3.
This is Mary and Tom Poppendieck’s take on agile software development. It takes its cue from lean manufacturing practice and develops this as seven principles supported by twenty two tools. Those familiar with agile approaches will find much that is familiar, the difference here is the lessons learned from other manufacturing disciplines: Toyota’s seven wastes is adapted for software, with a useful reinterpretation of unnecessary motion, something that I instinctively reacted against in its manufacturing incarnation. There are also some thought provoking sections on queuing theory and cost models for software products and applications. The tools, many familiar, cover the spectrum of software development practice from the technical: iteration, refactoring, developer/customer testing, through to the human and social aspects; management, leadership, motivation. I particularly liked the value stream map – simply sketch out the timeline to get a change or feature into use.  They are quite rude about traditional project management, claiming it is the wrong model for managing software development, over-emphasising cost and schedule, and are (just about) polite about the CMM but dismissive of CMMI. Chapter eight provides some advice on making lean software development happen; good advice to moderate the over zealous. There is also a brief section describing software development cultures, what they call ‘special work environments’ – government contract, safety critical, distributed development…etc. It is a pity this was not developed more. Understanding the needs and constraints of these different environments is critical to the success of new or changed development practices. This is a good read, it will engage you. I found myself thinking ‘Yes, but…’ time and time again. I wanted to discuss this with the authors.  There are a couple of reservations. I wonder if there is enough information in the book to try to use the tools listed. One, measurement, has some interesting ideas – measure up to avoid sub-optimization – but measurement is discussed very briefly almost as problem rather than a tool. There is also a degree of partisanship, which is fun but can be unhelpful; this is part of the publishers Agile Software Development Series. These are serious ideas, but the tone may be misinterpreted to imply that everything else is wrong; controls and software engineering disciplines, advocated and described at length in models such as the CMM can be discarded. I hope this is not intended. All software development requires disciplines and controls, as the authors acknowledge, but their application lies on a very broad spectrum. An important skill for software (production) engineers is selecting the right approaches, rather than being faced with an Agile/Non Agile(?) dilemma. Good book, but read carefully and critically. CCS March 2005








Two recommendations from Dez Cass at BAE Systems. Both these are available from Amazon.  “I have two books that I have referred to on many occasions when struggling with the deployment of quantitative management techniques in the software world.  These are:


40. Understanding Variation. The Key to Managing Chaos, Donald Wheeler, SPC Press,

ISBN 0-945320-35-3


39. Measuring the Software Process. Statistical Process Control for Software Process Improvement

William Florac & Anita Carleton, Addison Wesley, ISBN 0-201-60444-2 -  (highly recommended)”








38. Refactoring: Improving the design of existing code, by Martin Fowler, pub. Addison Wesley, 1999, ISBN 0-201-48567-2.
Finally got around to reading it – and enjoying it too… looking good, but a way to go yet. I’m not sure whether I haven’t ‘got it’ yet or it’s obvious good practice. If nothing else it’s a painless way to improve your Java… but…








37. Test-Driven Development: By Example, by Kent Beck, pub. Addison Wesley, 2003, ISBN 0-321-14653-0.
As it says on the back cover ‘A new idea? Not at all…’ TDD isn’t a new idea, but it is a good one. It is described here clearly and simply by the person who has developed it. Much of TDD will be recognized by those software developers that habitually test as they code. TDD develops this approach as a tool-supported, automated method for producing defect free code, and as a way of reducing uncertainty and fear - programmers will recognize that too. The scope TDD is difficult to describe in conventional test terms. It is recognizably related to the code/debug cycle and traditional unit test, but its completeness and suitability as a complete testing solution, replacing conventional integration and system test too, especially for large complex systems, should be considered carefully. Part one is worked examples in Java using JUnit. Part two develops xUnit in Python, using TDD of course, and part three describes some testing patterns and the characteristics of TDD. This is not a reference book but an ideas book; work through it to understand the approach. If you are looking for a test ‘cook book’ this isn’t it. If there is a concern it is that TDD integrates testing with producing code so closely, with tests and code growing together, that the tests may be compromised; that the tests and code converge on getting a ‘green’ to demonstrate the code works rather than searching out defects. That said TDD requires tests first, then code, and that is far better than the usual code/debug/hope for the best cycles employed by many. CCS November 2004








36. The Visual Display of Quantitative Information by Edward W. Tufte, pub. Graphics Press, 1983.
Describes how to design correct and informative graphics from numerical data. Anyone producing statistical presentations will probably turn to computer software tools. This book will help limit the excesses those packages encourage. It is a very useful, and beautiful, book. CCS November 2004








35. Design Methods: Seeds of human futures by J. Christopher Jones, pub. Wiley, 1980, ISBN 0 471 27958 7.
This book is out of print now and may be difficult to get hold of. I got our copy second hand from Amazon; it apparently came from Bell Labs (Indian Hill). It is a strange book, not directly related to software engineering; the author is an industrial designer interested in the design process itself. The book attempts to describe a set of design approaches and when they should be applied. In describing these methods the author recognizes the true nature of design – the uncertainty, false starts, confusion and muddle essential for creativity – and understands that methods are tools for directing this creative process. Like Christopher Alexander’s books this one touches on something recognizable to every software engineer, and in particular will strike a chord with those in the agile camp. Approached with an open mind there is a lot to be mined from this book. If you are involved in process improvement you could find something useful here too. For several years now we have been attempting to identify and describe the tools for good process improvement and these seem to have many of the same characteristics of Jones’ design methods. It’s not an easy read, and it may be difficult to get hold of a copy, but if you have an interest in how software engineering is really done, beyond the bald facts of proprietary methods and tools it’s worth hunting down a copy. CCS October 2004








34. High Quality Low Cost Software Inspections by Ronald A. Radice, pub. Paradoxicon, ISBN 0964591316.
This book is a Trojan horse. The focus is on inspections but it contains far more. It gives a fascinating history of the development of inspections and the background to my yellowing copies of IBM’s inspections specifications.  It has a very clear description of the inspection process itself and the roles of the inspection moderator and other players are discussed in depth. All of this is supported with a detailed commentary and useful checklists and templates. If you are interested in software quality or are considering introducing, re-introducing or resuscitating inspections in your organization then this book will be a major resource. Buy copies for all your moderators – supply each of your moderators with a copy when they successfully complete their moderator training perhaps? What you also get in this book is a convincing demonstration of the value of measurement - there are numerous examples of the sensible use of measurement - and causal analysis, real process improvement. These is also get a chapter discussing the economics of inspections, if you hadn’t already been convinced of their value. The author is an ex IBMer and it shows. The downright, rational, engineering orientation is clear throughout. It has much in common with the books of Stephen Kan and Bob Grady. This should be borne in mind when using this book - many organizations just will not recognize the value of inspections, as the author clearly knows. This is the first time I have seen a discussion, in print, of the need and value of process data integrity. Raising this issue is often seen as some form of bad manners. This is the first edition of this book and there are a number of typos and other minor errors but this in no way detracts from the value of this important book. Buy it. CCS September 2004








33. Juran’s Quality Handbook, Fifth Edition, edited by Joseph M. Juran, A Blanton Godfrey, Robert E. Hoogstoel & Edward G. Schilling, 1999, McGraw Hill, ISBN 0-07-034003-X.
A major resource for everyone involved in understanding industrial quality management. Contains almost everything you could want to know about quality in manufacturing. It is also well written and easy to read so you can trawl through it for ideas and have it spark off new ideas too. Strangely the section on software development (20) isn’t particularly useful - interesting yes - but seems to lack the focus of the other areas. Don’t let this put you off though. There are huge amounts of material throughout this book that can be applied to software development. A great book that you should have access to.CCS February 2004








32. CMMI: Guidelines for Process Integration and Product Improvement by Mary Beth Chrissis, Mike Konrad and Sandy Shrum, 2003, Addison Wesley, ISBN 0-321-15496-7.
This is the reference for the CMMI models now in book form. The first part describes the CMMI; its rationale, use, and the structure to enable you to navigate the process areas. Those familiar with the SW CMM will find much that is familiar but recast, with some welcome elaboration, in this expanded model. In particular the incorporation of Basili’s GQM is to be welcomed. Those new to process and process improvement may be dismayed by the rather abstract and complex structures presented. Part two defines the process areas themselves. This is the heart of the book and the major resource for those working to improve performance. Like the SW CMM much of the value of the models is implicit - the structure of the processes and way they are described says as much about process engineering as the content. The content is simply good practice ready to be mined by process engineers. Like the SW CMM it is worth bearing in mind where this model comes from; part three lists the product team, steering group and reviewers. CCS 2003








31. 201 Principles of Software Development by Alan M Davis, 1995, McGraw Hill, ISBN 0-07-015840-1.
This book is built on a simple idea. On each small page state a piece of software development wisdom - examples: 'don't reinvent the wheel', ‘use effective test completion measures’ - justify it and supply relevant references. The wisdom is delivered as 201 principles partitioned broadly by development phase. It makes for a readable and accessible aide memoire. CCS 2003








30. Rebel Code by Glyn Moody, 2001, Allen Lane - The Penguin Press, ISBN 0-713-99520-3.
Glyn Moody give a detailed picture of the open source community by following the development of Linux and other open source projects. The story is fascinating but claustrophobic. The story is focussed squarely on people as individuals, rather than teams and the key players are necessarily all coding heroes. It's a pity there wasn't a little more about how the code is produced. Towards the end there is an interesting discussion on the future of open source and its effect on other economic models of software production - is open source parasitic on the more conventional approaches? We'll have to wait and see. CCS 2001








29. Prince2: A practical handbook by Colin Bentley, 1997, Butterworth Heinemann, ISBN 0-75-06-5330-2.
Prince2 is the UK's de facto Project Management Standard. It deserves to be better known - or more widely used -  than it is. This book by Colin Bentley goes some way to spreading the word. It provides a clear overview of PRINCE2 describing and explaining the components of the standard to build a convincing picture of an approach to project management that incorporates many best practices and is both robust and flexible. The author, Colin Bentley, has been central to the development of Prince2 and its precursors.








28. The Secrets of Consulting by Gerald M. Weinberg, 1985, Dorset House, ISBN 0-932633-01-3.
Condensed wisdom delivered with wit and humour and summarized as a set of 'rules'. The insights are - as usual with Jerry Weinberg - penetrating, the situations recognizable and the advice very sound. (I just wish I could remember to act on what I now know!)








27. Debugging the Development Process by Steve Maguire, 1994, Microsoft Press, ISBN 1-55615-650-2.
On the cover it says 'practical strategies for staying focused, hitting ship dates, and building solid teams', and that's a pretty good summary. This is a slim readable book with sound advice and real world examples showing a team leader or project manager can keep project objectives in sight and actively manage the project to achieve them. The book steers a middle course between the tendencies to either reject all controls or overload teams with bureaucracy and procedures. The bad coffee story was a useful illustration of the value of simple 'systems'. CCS 2001








26. The Cathedral and The Bazaar by Eric Raymond, 1999, O'Reilly, ISBN 1-56592-724-9.
A fascinating series of essays on the open source community's emerging challenge to Microsoft's domination of the software market. Eric Raymond describes the programmer culture, why programmers want to produce software, the value of software itself and how commercial enterprises have chosen to exploit this. Essential reading if you want to know how the future of software and software development is being decided. CCS 2000








25. The Dilbert Principle by Scott Adams, 1997, Boxtree, ISBN 0-7522-2470-0.
If you thought process improvement and software measurement were easy this book will remind you what you are dealing with, and show you what most software developers and managers will think of your efforts. CCS 1999








24. Rapid Development by Steve McConnell, 1996, Microsoft Press, ISBN 1-55615-900-5.
This is an excellent resource for those that have to improve their projects' performance. Extremely readable, very practical: Steve McConnell discusses the motivators for improved development practice, the mistakes that are commonly made in attempting to improve practice and attributes of good software development practice. The book contains good advice and many examples of best practice. CCS 1997








23. Code Complete by Steve McConnell, 1993, Microsoft Press, ISBN 1-55615-484-4.
A highly readable and comprehensive reference book for every programmer. This impressive book is packed with clear thinking, good advice and numerous examples for the construction of good software. Buy it, read it and keep it by you. CCS 1997








22. Decline and Fall of the American Programmer by Edward Yourdon, 1993, Yourdon Press, ISBN 0-13-191958-X.
Ed Yourdon gives an overview of the problems facing software engineering and the practices that may help software development organizations maintain a competitive advantage. CCS 1998








21. Handbook of Walkthroughs, Inspections and Technical Reviews by Daniel P Freeman and Gerald M Weinberg, Third Edition, published by Dorset House, ISBN: 0-9326633-19-6.
This is an important book because it describes the most important software activity - reviewing. Human based quality control has almost an almost magical effect on software development and software management. This book describes the various types of reviews and their pros and cons in great detail. Unfortunately this (third) edition of the book has an unhelpful format. It is structured entirely as a series of questions and answers. This can be very frustrating; the authors have assumed they know the questions the reader would ask - but they don't. For this reason the book compares badly with Tom Gilb and Dot Graham's book on Software Inspections. Never the less this is an important book on an important software practice.








 For reviews 1 to 20 see  http://www.osel.co.uk/earlylibrary.htm



 What’s New     PODS    Products & Services    Library    Presentations & Papers    Related Sites    Events     History    Clients

© Copyright OSEL 1998-2011
This page was updated on 12/12/2011
Comments about this website to