|
|
|
|
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 contact mailto:shelley@osel.netkonect.co.uk
|
|