I just finished a book I found hard to put down, Better, by Atul Gawande. Atul is a surgeon in Boston who writes for the New Yorker and has published a couple of books. I love his essays and thoroughly enjoyed his first book, Complications: A Surgeon’s Notes on an Imperfect Science. In Better, Atul takes an unabashed look at how the medical profession can do things well, better. He uses examples ranging from the US Military Iraqi battlefield techniques to a Minnesota doctor’s relentless focus on helping Cystic Fibrosis patients live longer. One of the most exciting things about his writing is his ‘spock’ like ability to examine the things that go well and the things that go poorly. It isn’t good or bad, it’s something we can learn and improve on.
So, how does this relate to building software? Well, at the end of the book he comes up with five things we can do to be a ‘positive deviant’.
**Ask an unscripted question. **Often times we are caught up with the task at hand and we don’t the time to make more human connections with co-workers. I bet this would go a long way to helping inter-disciplinary understanding (See Troy’s Post).
**Don’t Complain. **Keep the conversation moving in a positive direction. Sure we don’t need to ignore uncomfortable things, but after too many complaint sessions we all walk away feeling angry and sorry for ourselves. This isn’t likely to help us get better at software development.
Count something. This one is always fun. Counting things is great. I love looking at the analytics of our internal wiki/blog tools. It’s a great way to get a sense of how much we are collaborating and finding the peaks and valleys. I once spent a couple of late night hours on a project writing regex statement to determine how many lines of code each developer wrote and how many bugs were assigned to them. As a team we loved looking at the numbers and worked to come up with different ways to look at performance and improve on it. This happens all too rarely.
**Write something. **It’s the process more than the content, Working through an essay, blog post, or white paper helps us clear our thoughts and get a sense of our larger purpose. It’s good stuff, even if it feels like a challenge to find the time.
**Change. **Something we hear with just about every project we start is, how can we get it down faster and once it’s down, how can we change it faster. It feels like the answer is change. This is what excites me about technology like Grails(see Jo’s Post) and Ruby on Rails. It’s what excited me about Java 1.0 over C back in the day. So, what are the changes we need to make to get things done faster? Can we do things before the user experience, creative and business teams finish or even start defining them?