Wilson GregOram Andrew. - Making Software

Copyright 2010 O'Reilly Media, Inc.

OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (.

Nutshell Handbook, the Nutshell Handbook logo, and the OReilly logo are registered trademarks of OReilly Media, Inc. Making Software , the image of the Arthur Ravenel Jr. Bridge, and related trade dress are trademarks of OReilly Media, Inc.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and OReilly Media, Inc., was aware of a trademark claim, the designations have been printed in caps or initial caps.

While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

The cover image is copyright Getty Images.

Does the MMR vaccine cause autism? Does watching violence on TV make children more violent? Are some programming languages better than others? People argue about these questions every day. Every serious attempt to answer the first two questions relies on the scientific method: careful collection of evidence, and impartial evaluation of its implications. Until recently, though, only a few people have tried to apply these techniques to the third. When it comes to computing, it often seems that a couple glasses of beer and an anecdote about a startup in Warsaw are all the evidence most programmers expect.

That is changing, thanks in part to the work of the contributors to this book. Drawing on fields as diverse as data mining, cognitive psychology, and sociology, they and their colleagues are creating an evidence-based approach to software engineering. By gathering evidence drawn from a myriad of primary sources and analyzing the results, they are shedding new light onto some vexing questions of software development. What do most programmers get wrong in their first job? Does test-driven development lead to better code? What about pair programming, or code reviews? Is it possible to predict the likely number of bugs in a piece of code before its released? If so, how?

The essays in this book will present answers to some of these questions, and explain why the jury is still out on others. Just as importantly, they will show you how to find and evaluate evidence yourself, both quantitatively and qualitatively. Every programmer is unique, and no two programs are exactly the same, but if you are careful, patient, and open-minded, they can be persuaded to give up their secrets.

We hope the questions and answers in this book will change how you think about software development. We also hope these essays will persuade you to say, Citation, please, the next time someone claims that one way of laying out braces in C or Java is better than another. And as with Beautiful Code (Andy and Gregs previous collaboration for OReilly), all author royalties will be donated to Amnesty International, which has been demanding answers to much more difficult questions than these for almost 50 years.