Book Review – The Cucumber Book

The Cucumber Book

Title: The Cucumber Book – Behaviour-Driven Development for Testers and Developers

Authors: Matt Wynne, Aslak Hellesøy

Rating: 4/5

Overall, a solid introduction to the Cucumber testing tool, and BDD in general. About the only criticism I have of it is that it’s perhaps a little bit too Ruby focused – an example of working with an application or a database without leveraging Rails would have been nice.

Continue reading “Book Review – The Cucumber Book”

Book Review – Peopleware

Title: Peopleware: Productive Projects and Teams

Authors: Tom DeMarco, Timothy Lister

Rating: 5/5

I picked this as the first book to review on my endless quest for two simple reasons:

  • It is one of my all time favourite books – a true timeless classic that really should be mandatory reading for every knowledge worker.
  • I have both the first and second editions on my reading list, so I can do a two-fer and review them both at once.

I bought the first edition in a 2nd-hand bookstore for $15 – the price is still on the inside cover. Two days later, I ordered the second edition for the eight all-new chapters.

Overall, the book holds its age well – it’s nearly 25 years old now, as it was first published in 1987. If they release a ’25th anniversary’ edition, do pick it up.


The book is broken into six sections – the last of which is for the second edition only. The sections are:

  • Managing The Human Resource – several chapters on people management skills
  • The Office Environment– all about building productive and distraction free environments
  • The Right People – covers how important it is to get the right people for your environment, not necessarily the most skilled or the cheapest.
  • Growing Productive Teams – pretty obvious; this is about how you nurture teams, how you can help make them gel, and how you prevent them falling apart.
  • It’s Supposed To Be Fun To Work Here – enjoyment and satisfaction in the work environment – what a novel idea!
  • Son of Peopleware – a reflection on the 12 years between the two editions, lessons learnt and new insights.

It’s a little dated in some ways. Some of the specific problems described in the book have gone away or reduced, while some of the specific solutions aren’t quite right anymore. But as a whole, the book is still highly relevant.

Each section is broken into several chapters. In the first part of the book, each chapter focuses on a particular issue. That may be a common negative phenomenon or anti-pattern – Chapter 3 is about overtime and workaholics, while Chapter 7 is about issues with ‘The Furniture Police’ – the people who don’t let you re-arrange workspaces to enable greater collaboration. Or it may be a positive workplace practise, such as Chapter 21 ‘A Spaghetti Dinner’, which describes a simple team-building exercise and why it works. Each chapter is short and focused – any chapter can be read in just a few minutes, which makes this a great book to read in spurts.


Here’s an example from one of the early chapters – Chapter 4 “Quality – If Time Permits”:

The Flight from Excellence

Managers jeopardise product quality by setting unreachable deadlines. They don’t think about their action in such terms; they tink rather that what they’re doing is throwing down an interesting challenge to their works, something to help them strive for excellence.

Experienced (jaded) workers know otherwise. They know that under the gun, their efforts will be overconstrained. There will be no freedom to trade off resources to make on-time delivery possible. They won’t have the option of more people or reduced function. The only thing to give on will be quality. Workers kept under extreme time pressue will begin to sacrifice quality. They will push problems under the rug to be dealt with later or foisted of onto the product’s end user. They will deliver products that are unstable but not really complete. They will hate what they’re doing, but what other choice do they have?”

The chapter goes on to talk about how people don’t explicitly value quality – that given the choice between getting a barely working product on time and on budget, or getting the stable complete version a few weeks later for a correspondingly greater price, they tend to pick the former. And if it’s going to be on time and high quality, they’d rather have it earlier and buggier. While this culture is endemic – and any real world project will face pressures on both time and budget – a willingness to accept the merely adequate is a killer for craftsmanship. Another quote from the same chapter:

Allowing the standard of quality to be set by the buyer, rather than the builder, is what we call the flight from excellence. A market-derived quality standard seems to make good sense on as long as you ignore the effects on the builder’s attitude and effectiveness.

In other words, good people want to build good products that they are proud of. Having worked in more than one environment where building good products was always a struggle, this is a principle I can agree with at a gut level.


The book does have some gaps. In particular, it assumes that knowledge workers should work alone or in pairs, even when part of a collaborative team – this runs counter to some of the various Agile methodologies I’m a fan of, which put emphasis on the benefits of a co-located team working in a communal area. That said, there is little in this book I disagree with, and a lot that I’m in violent agreement with.

If I could make any manager I report to read just one book, it would be this one. If I could make them read a dozen, this would be the first – closely followed by several others by the same authors (“Slack”, by deMarco, is another favourite). It doesn’t matter that some of the advice in this book is 25 years old – it’s still important.

Installing Grails from Source

 

Having converted the customer-facing pages of Wotif.com from a Freemarker/WebWork/EJB stack to a Grails/Spring3 stack earlier this year, I’m now officially a huge Grails fan. In setting up a new dev box, I wanted to install it – but who wants to install a download, huh? I wanted to build it from source (you can tell I’m a former Gentoo user!). Here’s what I did.

Continue reading “Installing Grails from Source”

My Book Collection

Well, the technical ones, anyway – not shown are the two other similarly sized bookcases – and the other one which is a little more than twice as big – which are overflowing with my fiction collection.

(Click to embiggen)

The bottom two shelves (and a couple in the third row) are very dated – I don’t think anyone cares about the pre-OS7 Macintosh Toolbox anymore, for example. A number of the books in that row are from my university days.

The next three rows (including the slight spill over to the top row, which will soon force me to relocate the DVDs) are a more recent vintage – those are the books that I kept at work while I procrastinated about unpacking my study (Hey, I only moved in just under two years ago!). But I finally did that on the weekend, and now they’re home (except for a few I’ve lent out)

I gotta say, I’m thankful for ebooks – over the last two years, I’ve predominately bought ebooks. I’m not sure I could get their physical versions on the top shelf even without the DVDs (it would be another 24 books or so).

Anyway, the reason I’m posting this isn’t to brag or anything – it’s to set myself a challenge. I haven’t been keeping up with my reading over the last year for a number of reasons, up to and including battling with a moderate case of depression. I’m going to change that though – I’m going to go through those top shelves and re-read (or, in a few cases, read) each on that’s still relevant – which is most of them. I mean, I’m sure Webwork In Action was great in the day, but Webwork isn’t relevant to me anymore. Age isn’t a factor, though – in that bookcase somewhere is a 2nd-printing copy of The Mythical Man Month (which I picked up in a Lifeline store for $5!), and I’ve got both the original and the re-issue version of Peopleware in there. Then there’s the Psychology of Computer Programming – but that’s from the 20th anniversary printing.

Anyway, my challenge – to myself – will be to read and post a review of the books in there. One a week, with the first review due next Saturday (October 1), with an e-book thrown into the mix every so often as well. I’ll post a full set of the books within the next few days, and I’ll even see if I can turn it into a poll of sorts in case there’s books people want me to review first.

Watch this space for more.

Updated: You can see my Delicious Library collection, or you can view the page that will become a dynamic view over my books (but right now is just static)

Post-Release Testing – what’s that about, anyway?

One of the odder practices of “conventional” software development that I’ve ever come across is the post-release test cycle. It’s something that has baffled me ever since I first saw it; you go through the normal development cycle, including testing, and then you deploy to production – and then you test it again. Sometimes with test cases that weren’t done during development. Why?

Continue reading “Post-Release Testing – what’s that about, anyway?”

Git, Feature Branches, and Jenkins – or how I learned to stop worrying about broken builds

I mentioned in my last post how we have started using Feature Branches with Git and Jenkins. In that, I rather casually mentioned that

“The build server uses the Git plugin for Jenkins to monitor all the branches on the local repository. Whenever a developer pushes to the repository, Jenkins will see the change and try to merge it into the stable branch. If the build passes, the merge is committed. If it doesn’t pass, the FeatureBranch doesn’t get merged – and it will stay unmerged until another change is made against it.”

This feature means that broken builds have almost no impact on team productivity. In fact – it can even be more productive to allow a broken build than to try to prevent it all the time.

Continue reading “Git, Feature Branches, and Jenkins – or how I learned to stop worrying about broken builds”

Making Parallel Branches meet regularly with Git and Jenkins

If you’ve been following my tweets recently, then you’ll know that we’ve recently converted the majority of our projects at work from Subversion to Git for our source control. We didn’t just do this because we wanted to play with a new shiny toy, but because we hope to achieve a new way of working. That’s what I want to describe here.

Continue reading “Making Parallel Branches meet regularly with Git and Jenkins”

Git Tip – Use different SSH keys per server

A lot of public git repos are configured around the use of SSH keys for authentication. It’s a good idea to use different keys for each server.

Doing this requires two steps:

  • create a unique key for the server (and submit it as normal)
  • configure your SSH client to use the new key just for that server

Creating the key is easy (Linux/Mac – sorry, Windows users) – ssh-keygen -f ~/.ssh/site_key (rename site_key as appropriate)

Then, you need to add a section like this in your ~/.ssh/config file:

Host    site_name
IdentityFile ~/.ssh/site_key

(Again, change site to whatever is appropriate)

Congrats! You’ve now got a unique key just for one site – this means if they happen to get compromised, all you need to do is regenerate the key, and away you go.

(Of course, you may want to use passphrases, and other appropriate measures, on your end – but that’s good advice anyway)

Agile – it’s not about the tools you use

The title says it all, but I thought I’d spend about eight hundred or so words saying more. 😉

I’ve seen a number of people think that “being Agile” is about having a build server, or about using Kanban, or an Agile project management tool. It’s not about unit testing, or pair programming, or continuous delivery, or devops, or any of a hundred other buzzwords. Don’t get me wrong – well performing Agile teams will be using these kind of tools and practices. But that’s not what makes them Agile.

Continue reading “Agile – it’s not about the tools you use”

Carbon Tax Thoughts – “That’s not a tax – it’s an ETS”

What a lot of people haven’t seemed to understand about the carbon tax is that it’s not a tax. It’s actually a way to transition from a “pollute-all-you-want” model to a capped-permit model – the ETS.

In order for an ETS to work, you need to have permits to pollute, issued by the government at a price. In order to developed a market for the permits (the ‘T’ stands for trading, after all), you need to have a finite number of these permits, so that companies can sell the permits that they don’t need. You also need penalties for the people who pollute without the permits.

The ‘carbon tax’ is an introduction of a uncapped permit scheme. With no upper limit on the number of permits, there’s no secondary market, but what this does do is help the government work out how many permits are required. Then, in 2015, the government is going to limit the number of permits it issues each year. Companies will still be able to buy them from the government – until the permits run out. After that, they can either buy them from the general market, OR pay the fine for polluting without a permit (this will set an upper-cap on the market price).

Labelling it a carbon tax is largely an exercise in both smear politics and lazy journalism (and it doesn’t help that the politicians have accepted the term ‘carbon tax’ as a moniker).

For a summary – in the government’s own words – see the Clean Energy Future site.