Author: Greg Brown
Reviewer: Kay Ewbank
Most programmers focus on writing the best possible code, but this book shows the importance of other aspects of development work.
This is a book that argues that writing the code is the easy part of being a software developer; the tricky bit is the other 90% - everything from requirements discovery to business analysis and designing for easy maintenance.
The book is written as a series of stories, each taking up a chapter. In each case you, the developer, are the main character. The idea is that the stories will make you think about the different elements around the actual coding.
The stories make interesting reading, and explore eight main ideas. The first chapter is all about using prototypes to explore project ideas. The point Greg Brown wants to get across is how to use things wireframes to work out with the client what functionality they expect; to get a live test system going, and to limit the scope of your work while checking your assumptions.
Next comes a chapter on spotting hidden dependencies in incremental changes. This is essentially a chapter on how there's no such thing as a standalone feture, so any change has consequences.
Indentifying pain points of service integration is next on the list. This chapter is about how best to work with services that change or worse, disappear, and how to minimize the problems.
A chapter on developing a workable approach to problem solving, which like quite a lot of the rest of the book sounds as though it's stating the blindingly obvious, but turns out to make useful points.
Other chapters cover designing software from the bottom up, data modeling in an imperfect world, and gradual process improvement as an antidote for over commitment. In each case, Greg Brown uses the story describing a programming situation to describe how problems arise, and how the chapter topic can make the best of the situation.
This is a short book, with little or no discussion of programming theories and techniques. Written down, the chapters might sound obvious, but reading the stories made me think about times when I'd not gone through those processes then regretted it later!
I think most programmers would either learn a new technique or benefit from having a familiar technique discussed in a way that reminds us of its value.
A worthwhile (and quick) read.
To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on, Twitter, Facebook, Google+ or Linkedin.
The Design of Design: Essays from a Computer Scientist
Software Project Secrets