Finishing Up Better

andyleonard — Mon, 05 May 2008 03:01:00 GMT

More Better

Last week I read and blogged about Better by Dr. Atul Gawande.

In Part III of the book, Dr. Gawande focuses on Ingenuity with three chapters entitled The Score, The Bell Curve, and For Performance. There are lots of good takeaways for software development in these chapters.

Full Disclosure

One stood out in particular in The Bell Curve. This chapter's use case is Cystic Fibrosis treatment centers. The Cystic Fibrosis Foundation (CFF) has been collecting statistics on centers around the United States for decades. Motivated by a grant from the Institute for Health Care Improvement, the centers began "opening up" about their performance compared to other centers.

Everyone wants to feel like they're doing a good job - in medicine, software, and every other field on the planet. Almost everyone has good and noble intentions. But some folks just do things better than everyone else. Why not identify those folks - those Positive Deviants - learn what they're doing that's so different, and try to reproduce those results everywhere?

Excellent question.

The answers are difficult because they cover the range of excuses for every bad idea ever conceived in human history. In the best case and strictest sense of the word, it's due to ignorance: People simply do not know any better - they're doing the best they can. The worst case is probably incompetence with a dash of malice to hide the fact.

Opening up changes things. It opens the door for the sharing of best practices by those who have developed and are practicing them. How cool.

Pulling Away

Perhaps the most potent example of best practices is found in a statement about the leading CF centers:

"You look at the rates of improvement in different quartiles, and it's the centers in the top quartile that are improving fastest," [Bruce] Marshall [the head of quality improvement for the foundation] says. "They are at risk of breaking away." What the best may have, above all, is a capacity to learn and change - and to do so faster than everyone else.¹

This theme, while emphatically true and accurate, is abused by Performance-Based Management. Beware too much of a good thing, regardless of the thing.

Conclusion

There are ways for us to do our jobs better. We can make software with higher quality and lower maintenance costs. We need to embrace the principles outlined in Better, identify and mimic those people who are Positive Deviants, and overcome all obstacles between the current state of affairs and our goal.

I not only know we can, I believe we're well on our way.

:{> Andy

¹Better, Dr. Atul Gawande, p. 227.

Dreaming In Code

andyleonard — Sun, 20 Apr 2008 03:50:00 GMT

A month or so back I was perusing MSDN Blogs and followed a link to the Dreaming In Code website.

I bought it and finished reading the book on my way home from the MVP Summit last week. I recommend it to anyone who wishes to learn more about large software projects.

The book offers a look behind the scenes at the design and development of an open-source Personal Information Manager project named Chandler. Chandler was initially touted as "The Outlook Killer" and the book describes Mitch Kapor's frustration with Exchange as one motivation for starting the project.

I found the book a fascinating look into

the work that goes into large projects;
the team dynamic as applied to software design and development;
open source development.

The book is slightly biased towards open source development and the open source community, but it's subject is an open source development project so the bias is expected. That shouldn't prevent anyone from reading the book. The challenges and pitfalls of producing great software bear no respect for platform or language.

One of the points the author drives home is how little we as developers and IT professionals study our own field. If you read my ramblings, you are probably not in that crowd.

The book's conclusion (and several reviews) led me to believe the project is a failure. I disagree - I don't think it's finished yet. Some things take time. Good software sometimes - often, in fact - takes more time than anyone can foresee at the start.

:{> Andy

Andy Leonard : Books, Software Business, software developers

Finishing Up Better

Dreaming In Code