Wrox code leader using people tools and processes to build successful software may 2008 ISBN 0470259248 pdf

Code Leader
Using People, Tools, and Processes to
Build Successful Software
Patrick Cauldwell

Wiley Publishing, Inc.



Code Leader
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Part I: Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1: Buy, Not Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapter 2: Test-Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 3: Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Part II: Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Chapter 4: Done Is Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Chapter 5: Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Chapter 6: Source Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Chapter 7: Static Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Part III: Code Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Chapter 8: Contract, Contract, Contract! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Chapter 9: Limiting Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Chapter 10: The Model-View-Presenter (MVP) Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Chapter 11: Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Chapter 12: Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Part IV: Putting It All Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Chapter 13: Calculator Project: A Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Code Leader



Code Leader
Using People, Tools, and Processes to
Build Successful Software
Patrick Cauldwell

Wiley Publishing, Inc.


Code Leader: Using People, Tools, and Processes to
Build Successful Software
Published by
Wiley Publishing, Inc.
10475 Crosspoint Boulevard
Indianapolis, IN 46256
www.wiley.com

Copyright © 2008 by Wiley Publishing, Inc., Indianapolis, Indiana
Published simultaneously in Canada
ISBN: 978-0-470-25924-5
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
Library of Congress Cataloging-in-Publication Data is available from the publisher.
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form

or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as
permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior
written permission of the Publisher, or authorization through payment of the appropriate per-copy fee
to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978)
646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley
Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or
online at />Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or
warranties with respect to the accuracy or completeness of the contents of this work and specifically
disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No
warranty may be created or extended by sales or promotional materials. The advice and strategies
contained herein may not be suitable for every situation. This work is sold with the understanding that
the publisher is not engaged in rendering legal, accounting, or other professional services. If professional
assistance is required, the services of a competent professional person should be sought. Neither the
publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or
Website is referred to in this work as a citation and/or a potential source of further information does not
mean that the author or the publisher endorses the information the organization or Website may provide
or recommendations it may make. Further, readers should be aware that Internet Websites listed in this
work may have changed or disappeared between when this work was written and when it is read.
For general information on our other products and services please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317)
572-4002.
Trademarks: Wiley, the Wiley logo, Wrox, the Wrox logo, Wrox Programmer to Programmer, and related
trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the
United States and other countries, and may not be used without written permission. All other trademarks
are the property of their respective owners. Wiley Publishing, Inc. is not associated with any product or
vendor mentioned in this book.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may
not be available in electronic books.


To my wife Vikki, who has supported me through many wacky endeavors, taken up the slack

when I’ve overcommitted myself, and generally been the best wife and mother ever.



About the Author
Patrick Cauldwell somehow found his way to a career in software despite earning a bachelor’s degree
in East Asian Studies. From a work-study job in the student computer lab at college through early jobs
in quality assurance and localization, and finally into full-time software engineering, Patrick has always
been interested in what makes computers tick. He’s worked in a wide range of software operations, from
very large projects at Intel to a very small start-up to a consulting job in the midst of the .COM boom.
Patrick pursues his passion for talking and writing about software development as often as possible.
He teaches computer science classes at the Oregon Institute of Technology, speaks at numerous developer conferences across the country, and once talked about the challenges of building a highly scalable
eCommerce web site as part of a 12-city developer road show.
After working for several product companies, Patrick recently returned to consulting full time.



Foreword
I have worked with Patrick Cauldwell, in one form or another, at two different companies for more than
half of my 15-year career in software. He has been almost a constant in my professional life, and I am a
better programmer for working with him. Why am I telling you this, dear reader, and why should you
care? Because you should always strive to surround yourself with people who are smarter than you, and
when you can’t, you should at least read their books.
Patrick is a pragmatist with a purist’s knowledge. He has a deep understanding of what ‘‘smells’’ right,
and he knows when and how to find the right balance to get the job done. This philosophy of balanced
‘‘pure pragmatism’’ pervades this book and makes it useful.
He moves back and forth between code and prose as if they were the same thing — useful, because
for many of us, they are. Rather than including large formal code listings and leaving the reader huge
chunks of code to grok, he weaves code in and out of his prose with the result being a practical, eminently readable book about the art and science, but most importantly, the process of modern software
engineering.

There are dozens of books that include lists of tools and techniques, but few attempt to put these tools
into the larger context of actually shipping successful software. I’ve found, while reading this book, that
it’s full of concepts that are intuitively obvious, but often forgotten within the scope of a large project. It’s
so nice to not just be preached the what and the how, but also the why. These are the practical concepts
that we aren’t taught in school, but only learn after hard-won battles in the real world.
Scott Hanselman
Author of ComputerZen Blog, www.computerzen.com
Senior Program Manager, Developer Division, Microsoft Corporation



Credits
Acquisitions Director
Jim Minatel

Production Manager
Tim Tate

Development Editor
Maryann Steinhart

Vice President and Executive Group Publisher
Richard Swadley

Technical Editor
Douglas Parsons

Vice President and Executive Publisher
Joseph B. Wikert

Production Editor
Dassi Zeidel

Project Coordinator, Cover
Lynsey Stanford

Copy Editor
Foxxe Editorial Services

Proofreader
Kathy Pope, Word One

Editorial Manager
Mary Beth Wakefield

Indexer
Robert Swanson



Acknowledgments
Big thanks to Scott Hanselman, who has long been a good friend and who has always encouraged me to
tackle new challenges. Thanks also to Chris Brooks and Tom Cook, who gave me the chance to put many
of the ideas in this book into practice. I would also like to thank Jim Minatel, Maryann Steinhart, and the
rest of the folks at Wiley for making this book possible.



Contents
Introduction

xxi

Part I: Philosophy
Chapter 1: Buy, Not Build
Cost versus Benefit
Creating a Competitive Advantage
Base Class Libraries
Open Source Software

Taking Advantage of Your Platform
Design
Risk
Services

Third-Party Components
Summary

Chapter 2: Test-Driven Development

3
4
5
6
7

7
7
8
9

9
10

11

Tests Define Your Contract
Tests Communicate Your Intent
Summary

13
16
19

Chapter 3: Continuous Integration

21

Integrate Early and Often
Keeping Testers Working
Keeping Developers Working
Barriers to Continuous Integration

Build Servers
Automating a Build Process
Expanding the Build Process
Setting Up a CI Server
Multiple Builds of the Same Project
Coordinating Build Output
Notifying People about Build Results

22
22
22
23

25
26
29
31
35
35
36


Contents
Fix a Broken Build before Integrating Changes
Summary

37
39

Part II: Process
Chapter 4: Done Is Done
Discuss Design Decisions
Every Class Has a Test Fixture
Each Fixture Exercises Only One Class
Code Coverage Is High
No Compiler Warnings
Static Analysis Tools Generate No Errors

Before Committing, Update
Documentation in Place
Summary

Chapter 5: Testing
Why Testing Doesn’t Get Done
How Testing Will Make You a Better Developer
Your Designs Will Be Better
You’ll Have to Write Less Code to Achieve Your Goals
You Will Learn More about Coding
You Will Develop Better Relationships with Your Testers
You Will Make Your Project Sponsors Happy

Code Coverage
Why Measure Code Coverage
Code Coverage Tools
Strategies for Improving Code Coverage

Types of Tests
Unit Tests
Integration Tests
Functional Tests
Performance Testing

Test Automation
Strategies for Test Automation
Testing Frameworks
Automation and Your Organization

Summary

xviii

43
44
45
48
49
51
52
53
53
56

57
58
59
59
59
60
61
61

64
65
67
72

74
75

84
89
93

96
96
97
104

106


Contents
Chapter 6: Source Control
Some Source Control History
Concurrent Versioning System (CVS)

Picking the Right SCCS
Performance and Scalability
Locking Models
Cost
Atomic Commits
Branching
Merging
Integration with Other Tools
Reporting
Extensibility
Making Your Choice

Organizing Your Source Tree

Using TreeSurgeon
Packaging
Adding Folders to Work with Source Control

Making the Most of Branching
Version Branches
Integration Branches
Personal Branches
Task Branches
Merging Branches

Summary

Chapter 7: Static Analysis
Using Static Analysis Tools
NDepend
FxCop
Simian

Who Benefits from Static Analysis?
How to Integrate Static Analysis into Your Process
Summary

107
108
110

110
111
111

112
112
113
114
114
115
115
115

117
117
121
121

122
123
127
129
130
131

133

135
135
136
137
139

139

140
143

Part III: Code Construction
Chapter 8: Contract, Contract, Contract!
Public Interfaces

147
152

xix


Contents
Data Contracts
Summary

Chapter 9: Limiting Dependencies
Limiting Surface Area
Dependency Injection
Inversion of Control
Summary

Chapter 10: The Model-View-Presenter (MVP) Model
Why MVP?
What Is MVP?
Constructing the MVP Application
Testing MVP Applications
Summary

Chapter 11: Tracing
Different Kinds of Messages
Log Sources and Log Sinks
Activities and Correlation IDs
Defining a Policy
Making Messages Actionable
Summary

155
158

159
162
165
167
170

173
173
174
177
184
187

189
189
190
192
193
196

198

Chapter 12: Error Handling

199

Result Code Reading
Exception Throwing
Importance of a Policy
Defining a Policy
Where to Handle Errors
Summary

200
201
203
204
207
210

Part IV: Putting It All Together
Chapter 13: Calculator Project: A Case Study

xx

213

Wrapping Up

220

Index

223


Introduction
Writing software is a complicated business. Once upon a time, software was written by an exclusive
hacker priesthood that emerged from big businesses like the telephone company or big industrial concerns. Most of them were electronics engineers who needed to write software to control hardware devices
that they built. Those early ‘‘programmers’’ mostly did just that. They wrote code to solve tangible problems, such as opening and closing phone switches and making sure that conveyor systems in automobile
factories worked the way they were supposed to. A very few of them wrote operating system software
or device drivers or networking protocols. In my first software job, I worked with a very complex (for
1992) network backup program that backed up client PCs to a tape drive attached to a Novell server.
The system had to manage network traffic, multiple clients waiting for the same tape drive on the server,
full and incremental backup sets, and so on. That piece of software was written almost entirely by two
developers.
Those days are over. The vast majority of software today is written by professional software developers
to solve business problems. There is often no hardware device involved except for the PC itself. Online
commerce, business-to-business computing, financial and accounting software, and banking or healthcare software are what many if not most of us work on today. There are no device drivers involved, no
hardware switches, no robots — these are business problems that can be solved by software.
Along with changes in the nature of the problems to be solved with software has come a huge increase in
the complexity of the software systems that we must design and build. The advent of the Web has meant
that much of the software written today is designed to be distributed across more than one computer,
and potentially used by many hundreds of thousands of customers. It is no longer enough to write
software that solves a problem; it must also be fast, scalable, reliable, and easy to use. Ever since the
infamous .COM bubble burst, software must also be affordable, both to build and to support. Total cost
of ownership is becoming an increasingly important issue for software firms, sometimes more so than
building new features.
Luckily, the tools used to write software have improved at least as rapidly as the complexity of the
software has increased. Most software today, particularly business software, is written in high-level

languages that remove much of the drudgery once associated with day-to-day programming tasks. That
frees developers to concern themselves with solving business problems rather than with pure ‘‘coding’’
tasks.
The combination of these various trends has meant that professional developers can’t just be coders any
more if they want to advance in their careers. Gone are the days when a project could be saved at the last
minute by the heroic efforts of a super-genius coder. Although I’m sure that still happens here and there,
it certainly isn’t the norm. Most modern software projects are just too complicated to make that work.
Even a medium-sized software project these days is too much for one person to fully comprehend in all of
its detail. That means that we must work on teams on almost all software projects. Granted, that might be
a team of two or three in some cases, but more often it’s a team of 10 or more developers. That means that
to get ahead in the software industry these days you have to know just as much about how to help teams
work together as you do about writing code, even if you are not in a project management or personnel


Introduction
management role. A team lead, technical lead, or architect must be able to keep a team of developers
on track and working well together, just as much as he or she needs to be able to turn requirements
into code.
That isn’t to say that they should become project managers — that’s a completely different subject, and
this book is not about project management, although all of the topics covered in it apply equally well to
any project management methodology. It falls to the team lead to be familiar with strategies that make
it easier for teams of developers to work together in ways that enhance rather than detract from their
productivity.
Those strategies range from high-level development philosophies, such as Test-Driven Development
(TDD) or Continuous Integration (CI), to more concrete development process issues, from source code
control and static analysis to techniques involving code construction, such as programming by contract and how to deal with errors and tracing. Taken collectively, all these strategies and techniques are
designed to make it easier for teams of developers to work together in ways that allow them to coordinate
their work for highest productivity, and to produce software that is easy to build, support, and maintain.
In today’s software job market, those are ultimately the skills that separate the career professional from
the hacker, and the great developer from the average one.

Being able to write good code is still a prerequisite, of course, but there are several other exceptional
books that cover that subject in depth. Code Complete by Steve McConnell and The Pragmatic Programmer:
From Journeyman to Master by Andrew Hunt and David Thomas are excellent examples. If you want to
make the transition from solid coder to team lead, however, you need to know more than how to write a
tight for loop.

Who This Book Is For
This book is for the career developer who wants to take his or her skill set and/or project to the next level.
If you are a professional software developer with 3–4 years of experience looking to bring a higher level
of discipline to your project, or to learn the skills that will help you transition from software engineer to
technical lead, then this book is for you. The topics covered in this book will help you focus on delivering
software at a higher quality and lower cost. The book is about practical techniques and practices that will
help you and your team realize those goals.
This book is for the developer who understands that the business of software is, first and foremost,
business. Writing code is fun, but writing high-quality code on time and at the lowest possible cost is
what makes a software project successful. A team lead or architect who wants to succeed must keep that
in mind.
Given that target audience, this book assumes a certain level of skill at reading code in one or more
languages, and basic familiarity with building and testing software projects. It also assumes that you
have at least a basic understanding of the software development life cycle, and how requirements from
customers become testable software projects.

Who This Book Is Not For
This is not a book for the entry-level developer fresh out of college, or for those just getting started as
professional coders. It isn’t a book about writing code; it’s a book about how we write code together

xxii