A handbook, not a textbook, it is not tied to any particular operating system, platform, language, or methodology. Instead it focuses on principles and practices that have been proven in the real world. It is pragmatic, emphasizing the importance of what the author calls Adaptive Programming - doing what works in your situation, and it is concise, covering the whole software development lifecycle in one slim volume.

At each stage, it describes common pitfalls, explains how these can be avoided, and suggests simple techniques which make it easier to deliver better solutions.

"Well thought-out ... addresses many of the key issues facing developers of bioinformatics software."  (Simon Dear, Director, UK Technology and Development, Bioinformatics Engineering and Integration, Genetics Research, GlaxoSmithKline)

Here are some examples from the book itself. 

On software development:

“Writing software properly involves talking to people – often lots of people – and plenty of non-coding work on your part.  It requires the ability to dream up new solutions to problems so complicated that they are hard to describe.”

From description to specification:

“Look for verbs – action words, such as ‘does’, ‘is’ and ‘views’.  Identify nouns – naming words, like ‘user’, ‘home’ and ‘sequence’.  List the adjectives – describing words, for example ‘quick’, ‘simple’ or ‘precise’.

The verbs are the functions that must be provided by your application.  The nouns define the parameters to those functions, and the adjectives specify the constraint conditions under which your program must operate.”

On how to start writing software:

“Handle errors.  Take in data.  Show output.  Get going!”

On testing:

“It may not be physically possible to test every potential combination of situations that could occur as users interact with a program.  But one thing that can be done is to test an application at the agreed extremes of its capability: the maximum number of simultaneous users it has to support, the minimum system configuration it must run on, the lowest communication speed it must cope with, and the most complex operations it must perform.

If your program can cope with conditions at the edge of its performance envelope, it is less likely to encounter difficulties in dealing with less challenging situations.”

On showing early versions of software to users:

“It can be hard explaining the software development process to people who are unfamiliar with it.  Code that to you is nearly finished is simply not working to them, and seeing their dream in bits on the workbench can be disappointing to customers, especially when they were expecting to be able to take it for a test drive.”

On bugs:

“If your users find a genuinely reproducible bug in production code, apologize, fix it fast, and then fix the system that allowed it through.  And tell your customers what you are doing, and why, so they will be confident that it will not happen again.  Everybody makes mistakes.  Don’t make the same ones twice.”

And one last thought on successful software development:

"You have to be a detective, following up clues and examining evidence to discover what has gone wrong and why. And you have to be a politician, understanding what people want, both in public and in private, and how this is likely to affect what you are trying to do.  This book cannot teach you how to do all of that, but it can help."