Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Jolt Awards

Jolts 2007: Books General


Jolt Winner

Agile Software Development: The Cooperative Game
Alistair Cockburn
Addison-Wesley Professional

Chris Guzikowski, Editor; Stephen Nakib, Marketing Manager

Should you read by Alistair Cockburn's Agile Software Development, Second Edition?

Absolutely. The first edition of Agile Software Development proved to be fundamental reading for anyone serious about understanding what agility is really all about. This clearly holds true for the second edition, which adds new insights from one of the top thought leaders in the agile community. The true message of the book is that software development is a "cooperative game," and if we're to succeed at software development, then we need to find ways to work together more effectively than we currently do. Cockburn shares his understanding of how people communicate and collaborate throughout the book, comparing and contrasting various strategies in such a way that you begin to reflect upon, and question, some of your underlying assumptions as to how software development really works.

The book brings together several critical streams of thought within the agile community. Discussions of how agile and lean fit together, how agile and self adaption works, how theory of constraints fit in, and how a few concepts from martial arts can help to bring everything together. The book also provides an update on Cockburn's work with the Crystal Methodology family, making it abundantly clear that one process size does not fit all.

Agile Software Development, Second Edition is a "must read" for anyone who is trying to understand the underlying philosophical underpinnings of agile software development, what works in a given situation, and more importantly, why it works. This book is a "you better read it" if you are new to agile ideas and want something with some depth. Finally, this book is a "probably bought it the first day it came out" for anyone who read the first edition-the second edition is that good.

--Scott Ambler

Productivity Award

Catastrophe Disentanglement
E. M. Bennatan
Addison-Wesley Professional

If developers weren't optimists, we'd never write a line of code. "Can we build it?" "Yes we can!" When projects go astray, the tune hardly changes: "Can we fix it? Yes we can!" But, you know what? Sometimes, you can't.

Catastrophe Disentanglement, E. M. Bennatan, takes a hard look at a reality most of us have confronted: projects too dire to rescue by working harder, or working smarter, or thinking in new ways, or applying better tools, or any of the straws drowning developers grasp at. JUST STOP!

That's the first lesson of the book, and it's the hardest. When you find yourself at the bottom of a hole, STOP DIGGING! Catastrophe Disentanglement gives you objective criteria for recognizing when a project is standing in its own grave, and gives you a concrete checklist for analyzing what went wrong and determining how to either yank the project back on track, reinvent it so it's doable, or jettison it entirely. It's all backed up with a solid understanding of how people react when things are going wrong, and shows you how to move the discussion out of the realm of finger-pointing and guilt.

Just be prepared for some raised eyebrows when you leave it on your desk.

--Rick Wayne

Productivity Award

Practices of an Agile Developer
Venkat Subramaniam and Andy Hunt
Pragmatic Bookshelf

Practices of an Agile Developer Venkat Subramaniam and Andy Hunt is a very, very, very special book. Why? It is one of those rare books that gives operationally useful success criteria for hitherto fuzzy coding goals. There are a great many books that are theoretically exciting, but darn few that give you a gut-level test for "how it feels" when the theory is working and still fewer that try to help you "keep your balance" when you become blindly optimistic because of the idea's success, or bottom of the barrel depressed when the idea bombs.

Each of the book's practices has such codicils. For example, take the universally known idea "Keep it Simple." Partially excerpting the book, it feels right "when there isn't a line you could remove and still deliver all features." A sample keep your balance guide: "Terse is not the same as simple; it's just uncommunicative." More than 40 such practices are examined in detail, including lively discussions on how they affect the team, customers, system design, coding, and debugging. The heck with Agility, these nonideological guides work in any development environment.

Keep your balance. Study this book.

--Roland Racko

Productivity Award

Software Estimation: Demystifying the Black Art
Steve McConnell
Microsoft Press

Steve McConnell is no stranger to the Jolts, having won the Jolt award several years ago for Rapid Development: Taming Wild Software Schedules, and the productivity award for his post-dot com back-to-reality book, After the Gold Rush: Creating a True Profession of Software Engineering. Not one to shy away from the visceral issues challenging the leaders of software development, Software Estimation tackles this amorphous subject with an engineer's analysis and pulls the reader into a world of planning for the vagaries and uncertainties of more accurately modeling software development costs. The Jolt judges had quite a passionate discussion around this book because of the nerves that it struck with so many of us. Having been stung in the past by inaccurately estimating project duration and cost (I tend to be overly optimistic and sometimes fail to account for wetware constraints like sickness or sleep), I approached the book with skeptical enthusiasm. Although it failed to enrapture myself or fellow judges, it did spark lively conversations of our own estimation foibles and how the concepts in the book may deter future derailments.

--Mike Riley


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.