Sunday, 1 November 2009

Book Review: Coders at Work by Peter Seibel

Of the 15 names in the list I recognised just 7, so I can't claim to have a great knowledge of great programmers. But that just seeing Donald Knuth on the list made me want to read the book. And having read it, I recommend it to you.

( amazon.co.uk | amazon.com )



The interviews share questions so you get a common feel for how the interview subjects all learned their trade. But the interviews flow as conversations with Peter Seibel injecting the common questions as appropriate for the person.

All interview subjects pass on ‘pragmatic’ views rather than PC mainstream views, and most of them started developing these views when developers worked closer to the metal and software had fewer lines of code, sometimes in languages we barely remember.

I find reading interviews interesting but slow work, so it took me quite a long time to finish this book, despite reading a pre-release copy, I didn’t manage to get a review out until well after the book’s publication date.

I originally wrote a longer review, peppered with quotes and a serial walk through of all the interviewees, but you can do that when you read the book. Instead I have pared it back to summarise some of the things that came across strongly from the book for me:

  • work at your craft constantly,

  • read code to learn from other people,

  • write readable code – in some cases literate programming

  • keep thing simple,

  • build code, to ship products

  • build incrementally and functionally to learn quickly

  • do not over-engineer

  • keep learning “If you don’t understand how something works, ask someone who does.”

  • Use your app and have it running all the time.

  • Good programmers program for fun outside of work - not just during work

  • Think in subsets of languages and libraries – learn those subsets thoroughly and understand their limitations – use them based on appropriateness, complexity, applicability, and how well it lets you communicate

  • Ship it – re-factor it

  • Use static analysis

  • Hire for smarts and practical ability rather than random and abstract problem solving

  • Simplify

I also learned a few tips about naming conventions and commenting to allow scanning of code to pick up errors e.g. customerName and customerNames would instead have names like customerName and listOfCustomerNames to allow human reading/scanning to see the difference.

The various interviewees have strong opinions about programming languages, but I don’t remember any of them having found their perfect language.

Very few of them seemed to use IDEs, which suggests that they had in-depth and detailed knowledge of the language they coded in, and the libraries they used. Certainly, I use IDEs because I do not have that level of knowledge.

Automated testing doesn’t get covered very often by the interviewees, and those that do mention it cover it pragmatically – using it to automate the ‘clever’ code to guard against people changing it without understanding it.

Many of these programmers thought of themselves as writers – hence the emphasis on readable code and reading other’s code.

When not programming these people spend their time learning about and thinking about programming. The 10,000 hours to expertise comes through strongly in these interviews and they act as mentoring sessions. All of the interviewees have taken apart frameworks and other people's code to see how it works, they have all worked closely with other very good people so had many opportunities to learn. Even if you think the people you work with do not have the ‘greatness’ you desire to learn from then you could pick the code from open source projects to read - but you have probably underestimated some of the people you work with.

For me, as a tester – an old programmer, but not as great as I used to consider myself. The fact that all these very strong developers talk about simplicity, readability, writing.  Makes me feel better about my programming skills and gives me hope that by identifying subsets of the languages that I use well, I can still write good code.

“Coders At Work” links well with the notions presented in Kent Beck’s “Implementation Patterns”. And based on these two books I have subtly changed my approach to coding and now read more code.

Recommended reading for both developers and testers.

Related Reading:


Sunday, 2 August 2009

Book Review: Agile Testing by Lisa Crispin and Janet Gregory

One good thing about the title, it should mean that testers read the book. One bad thing about the title, other roles might not. But they should. This book provides a particularly good introduction and overview to the Agile process from a ‘test’ perspective.

( amazon.co.uk | amazon.com )



Anyone that has worked in an Agile environment for some time will read the book and relate very easily to the stories, philosophies and practices described – your danger is reading too fast and skipping over chunks that you can learn from.

Anyone not familiar with an Agile environment will get a massive head start after reading this book, you will not have to learn everything the hard way and you will read about many options open to you.

It does seem, from various questions in forums and the generally feeling of writing on the internet that many testers find it difficult to know what to do in an Agile environment. This book will answer many of the early questions and help the tester more confidently approach the project and engage with the other team members with the aim of creating a ‘whole team’ approach to testing.

I recommend this book unreservedly for testers new to Agile projects.

Project Managers would gain a lot from reading this as I found this book one of the most rounded and pragmatic books on Agile that I have read.

Developers would gain from understanding what testers do when they have their heads down coding, or even possibly what the testers ‘should’ be doing.

Agile presents a learning environment for everyone on the project so if your testers have not read this book – try subtly nudging them towards this book by dropping it with a resounding ‘thud’ on their desk.

Lisa and Janet have covered a lot of ground in the book and as a result it has bucked the recent trend for thin books. So you certainly feel like you get value for money, I just hope that most readers manage to work through it because the authors have taken great pains to build on the material throughout the book and cover some of the more subtle points of engagement towards the end.

Agile projects can differ greatly from each other and can offer different contexts for the tester. Each project starts at a different stage of learning and knowing when to push for certain techniques and tackle certain issues can prove hard to judge. So the authors have had to tackle the issue of providing generic advice in a way that the tester can make use of it when they most require it. Lisa and Janet have done this by adding short experience memories throughout the book – theirs and other Agile practitioners. They have provided generic advice and options. They also encourage the reader to experiment, to try out the practices, drop them if they don’t currently work – with the knowledge that they might work at a later stage on the project, and that sometimes they don’t need to use that on a project.

I really love constant reminder that Agile revolves around the team working as a team and that the testing on an Agile project requires the same team based approach because too many projects and teams that I have worked on split into their own disciplines even though we know that we will only succeed when the whole team conducts the testing, and when the testers get involved in the analysis, design and coding. Fortunately the book presents experiences of how to ‘gel’ the team – all of them communication based and all of them workable.

Very often in book reviews I attempt to summarise the chapters and pull out key points. Sometimes I find this very easy to do because the book actually has very little content. I will not attempt to do that for this book. Spread over 21 Chapters and more than 500 pages I found too much of relevance so I urge you to read it for yourself.

And having read the book, it then becomes a useful dip in and out reference, reminder, and paper based mentor on your desk.

Buy it.

Related Links:


Wednesday, 4 February 2009

Book Review: How We Test Software At Microsoft


Book Authors: Alan Page, Ken Johnston, Bj Rollison
I really enjoyed this book. I don't know if I learned a lot of new stuff but HWTSAM did remind me of a lot, and encouraged me to believe in a rosier future for all software testers.
HWTSAM makes it clear that because of Microsoft's size many styles of testing go on in Microsoft and this book presents some stories about Microsoft and some of their techniques. No company I have worked for has faced, has not even close to, the same testing problems as Microsoft. Microsoft builds and tests for the long term. No company I have worked in has built for the long term - if a product takes a few years to write and then lives on in support for 10 years, and you have a company culture that acknowledges that from the outset, then the development process changes wildly - and you get the Microsoft approach.
( amazon.co.uk | amazon.com )


With a ratio of testers:developers of 1:1, those testers keep busy by testing the product as it currently stands and building a test approach for the long term - and that involves automation, a lot of automation.
Rather than write 'one test book to rule them all' HWTSAM tells some stories, outlines some important techniques and approaches, and recommends the mighty Binder, Testing Object-Oriented Systems, specifically  chapter 3 "Testing: a Brief Introduction" (which i now have to go off and re-read).
The first few chapters describe Microsoft as a promised land where software developers and software testers live in harmony with each other, where everyone enjoys what they do with a high discretionary effort quotient. Joshing aside, the first 2 chapters present Microsoft as a great company to work for, one that really values the testing staff and reads as the best recruitment literature for any company I've ever read.
"Tester DNA has to include a natural ability to do systems level thinking, skills in problem decomposition, a passion for quality and a love of finding out how something works and then how to break it."..."now that is what makes up a tester that makes them different from a developer" (page 25)
I might quibble with the 'natural ability' part of the above but I really like the description as an attempt to say what makes a tester different from a developer.
Part 2 contains the Test Technique stuff. I like the unstated 'obviously testers will have enough technical ability to do all this' attitude that underpins this section. HWTSAM covers three big 'functional' techniques in depth: Equivalence Class partitioning, Boundary Value Analysis, and Combinatorial  Analysis - with enough side stories and details to make the coverage of the technique interesting even if you have familiarity with them. And although not yet in the 'tools' section - we learn about PICT 'the' tool for combinatorial testing.
The chapter on structural testing treats the technique as a pure 'white box' technique. I wouldn't limit structural techniques in this way since I use structural techniques on models I've generated without using the source code. Although hopefully this chapter helps dispels the notion that testers looking at source code is a baaaad act. Techniques covered: block testing, decision testing, condition testing, and basis path testing.
I really like the various 'asides'. As an example, one from chapter 6 "In the five-year study at Microsoft..." I love that, mentioned in passing, not drawing extreme attention to it, as though all companies do internal five year studies. This book has many examples and stories drawn from long studies in an effort to improve. Not your typical 'count this to improve' metric evangelising tales. Microsoft seem to have a deep seated culture of improvement and practical "so how will we know?" investigation - I think I found much of my value in these stories, and I have not properly assimilated it yet.
But honestly, the Model Based Testing chapter, far too short - but it still contained some good tips. The full story of Model Based Testing at Microsoft still sits out there; elusive, mythical, awaiting a telling. And I want to hear it. SpecExplorer gets a mention but it seems like the 'good' version will live inside Visual Studio rather than sit outside for everyone to use.
I haven't covered the contents in detail, when you read it you can learn all about:
Tools, automation, bug reporting, non-functional testing, built in customer feedback systems, services and the future - for yourself.
I expected more of a techniques book, instead I got a much more readable and enjoyable description of some of the testing life inside Microsoft. Plenty of stories to learn from and a description of a testing culture to aspire to.
Related Reading