Code Leader: Using People, Tools, and Processes to Build Successful Software (Programmer to Programmer) (Paperback)

~ (Author), Scott Hanselman (Foreword)
Key Phrases: continuous integration, calculator project, repository browser, Visual Studio, Code Construction, Test-Driven Development (more...)

Editorial Reviews

Product Description

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 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 lifecycle, 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 while keeping quality up and costs down. It is not for those who want to learn to write more efficient or literate code. There are plenty of other books available on those subjects, as mentioned previously.

This is also not a book about project management or development methodology. All of the strategies and techniques presented here are just as applicable to waterfall projects as they are to those employing Agile methodologies. While certain strategies such as Test-Driven Development and Continuous Integration have risen to popularity hand in hand with Agile development methodologies, there is no coupling between them. There are plenty of projects run using SCRUM that do not use TDD, and there are just as many waterfall projects that do.

Philosophy versus Practicality: There are a lot of religious arguments in software development. Exceptions versus result codes, strongly typed versus dynamic languages, and where to put your curly braces are just a few examples. This book tried to steer clear of those arguments here. Most of the chapters in this book deal with practical steps that you as a developer can take to improve your skills and improve the state of your project. The author makes no claims that these practices represent the way to write software. They represent strategies that have worked well for the author and other developers that he have worked closely with.

Philosophy certainly has its place in software development. Much of the current thinking in project management has been influenced by the Agile philosophy, for example. The next wave may be influenced by the Lean methodologies developed by Toyota for building automobiles. Because it represents a philosophy, the Lean process model can be applied to building software just as easily as to building cars. On the other hand, because they exist at the philosophical level, such methodologies can be difficult to conceptualize. The book tries to favor the practical over the philosophical, the concrete over the theoretical. This should be the kind of book that you can pick up, read one chapter of, and go away with some practical changes you can make to your software project that will make it better.

That said, the first part of this book is entitled “Philosophy” because the strategies described in it represent ways of approaching a problem rather than a specific solution. There are just as many practical ways to do Test-Driven Development as there are ways to manage a software project. You will have to pick the way that fits your chosen programming language, environment, and team structure. The book has tried to describe some tangible ways of realizing TDD, but it remains an abstract ideal rather than a one-size-fits-all technical solution. The same applies to Continuous Integration. There are numerous ways of thinking about and achieving a Continuous Integration solution, and this book presents only a few. Continuous Integration represents a way of thinking about your development process rather than a concrete or specific technique.

The second and third parts represent more concrete process and construction techniques that can improve your code and your project. They focus on the pragmatic rather than the philosophical.

Every Little Bit Helps: You do not have to sit down and read this book from cover to cover. While there are interrelationships between the chapters, each chapter can also stand on its own. If you know that you have a particular problem such as error handling with your current project, read that chapter and try to implement some of the suggestions in it. Don’t feel that you have to overhaul your entire software project at once. The various techniques described in this book can all incrementally improve a project one at a time.

If you are starting a brand new project and have an opportunity to define its structure, then by all means read the whole book and see how it influences the way you design your project. If you have to work within an existing project structure, you might have more success applying a few improvements at a time.

In terms of personal career growth, the same applies. Every new technique you learn makes you a better developer, so take them one at a time as your schedule and projects allow.

Examples: Most of the examples in this book are written in C#. However, the techniques described in this book apply just as well to any other modern programming language with a little translation. Even if you are unfamiliar with the inner workings or details of C# as a language, the examples are very small and simple to understand. Again, this is not a book about how to write code, and the examples in it are all intended to illustrate a specific point, not to become a part of your software project in any literal sense.

This book is organized into three sections, Philosophy, Process and Code Construction. The following is a short summary of what you will find in each section and chapter.

Part I (Philosophy) contains chapters that focus on abstract ideas about how to approach a software project. Each chapter contains practical examples of how to realize those ideas.

Chapter 1 (Buy, not Build) describes how to go about deciding which parts of your software project you need to write yourself and which parts you may be able to purchase or otherwise leverage from someplace else. In order to keep costs down and focus on your real competitive advantage, it is necessary to write only those parts of your application that you really need to.

Chapter 2 (Test-Driven Development) examines the Test-Driven Development (or Test-Driven Design) philosophy and some practical ways of applying it to your development lifecycle to produce higher-quality code in less time.

Chapter 3 (Continuous Integration) explores the Continuous Integration philosophy and how you can apply it to your project. CI involves automating your build and unit testing processes to give developers a shorter feedback cycle about changes that they make to the project. A shorter feedback cycle makes it easier for developers to work together as a team and at a higher level of productivity.

The chapters in Part II (Process) explore processes and tools that you can use as a team to improve the quality of your source code and make it easier to understand and to maintain.

Chapter 4 (Done Is Done) contains suggestions for defining what it means for a developer to “finish” a development task. Creating a “done is done” policy for your team can make it easier for developers to work together, and easier for developers and testers to work together. If everyone on your team follows the same set of steps to complete each task, then development will be more predictable and of a higher quality.

Chapter 5 (Testing) presents some concrete suggestions for how to create tests, how to run them, and how to organize them to make them easier to run, easier to measure, and more useful to developers and to testers. Included are sections on what code coverage means and how to measure it effectively, how to organize your tests by type, and how to automate your testing processes to get the most benefit from them.

Chapter 6 (Source Control) explains techniques for using your source control system more effectively so that it is easier for developers to work together on the same project, and easier to correlate changes in source control with physical software binaries and with defect or issue reports in your tracking system.

Chapter 7 (Static Analysis) examines what static analysis is, what information it can provide, and how it can improve the quality and maintainability of your projects.

Part III (Code Construction) includes chapters on specific coding techniques that can improve the quality and maintainability of your software projects.

Chapter 8 (Contract, Contract, Contract!) tackles programming by contract and how that can make your code easier for developers to understand and to use. Programming by contract can also make your application easier (and therefore less expensive) to maintain and support.

Chapter 9 (Limiting Dependencies) focuses on techniques for limiting how dependent each part of your application is upon the others. Limiting dependencies can lead to software that is easier to make changes to and cheaper to maintain as well as easier to deploy and test.

Chapter 10 (The Model-View-Presenter Model) offers a brief descr...

From the Back Cover

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

"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."
—from the foreword by Scott Hanselman, Author of ComputerZen Blog, www.computerzen.com; Senior Program Manager, Developer Division, Microsoft Corporation

Writing code is rewarding, but writing high-quality code, on time and at the lowest possible cost, is what makes a software project successful. As the role of a professional developer has evolved and taken on additional responsibilities, it is now necessary to work in concert with a team in order to improve both the process and final results of a software project. This unique book introduces a set of concrete best practices and construction techniques that can be applied to the development process and to actual code construction, so that you can confidently solve business problems rather than deal solely with pure coding tasks.

Patrick Cauldwell understands that it is no longer sufficient to just write software that solves a problem; it must also be fast, scalable, reliable, and easy to use. In this reference, he explains how to build software that is of high quality at a lower cost and shares with you the practical steps you must take in order to transition from software engineer to technical lead.

What you will learn from this book

• Practical steps you can take to combine different developmental philosophies, processes, and construction techniques into a unified approach to software

• Methods for deciding which parts of a project you need to write yourself versus what you can buy or reuse

• Tools and processes you can employ to improve source code quality and maintainability

• How to create, run, organize, and measure tests, and then make them more useful to developers and testers

• Ways that programming by contract can make your code easier for developers to understand and use

• Recommended techniques for handling errors in your code that will make your application easier to debug and support

Who this book is for
This book is for experienced software developers who are looking to improve their development skill set and bring a higher level of discipline to a project.

Wrox guides are crafted to make learning programming languages and technologies easier than you think. Written by programmers for programmers, they provide a structured, tutorial format that will guide you through all the techniques involved.

See all Editorial Reviews

Product Details

• Paperback: 233 pages
• Publisher: Wrox (May 5, 2008)
• Language: English
• ISBN-10: 0470259248
• ISBN-13: 978-0470259245
• Product Dimensions: 9 x 7.3 x 0.7 inches
• Shipping Weight: 14.4 ounces (View shipping rates and policies)
• Average Customer Review: 3.8 out of 5 stars  See all reviews (5 customer reviews)
• Amazon.com Sales Rank: #118,045 in Books (See Bestsellers in Books)

  Popular in this category: (What's this?)

  #26 in

  Books > Computers & Internet > Computer Science > Software Engineering > Design Tools & Techniques

Customer Reviews

Most Helpful Customer Reviews

7 of 7 people found the following review helpful:

4.0 out of 5 stars Round Out Your Skills, May 16, 2008

By	Travis Illig "Software Engineer" (Portland, OR United States) - See all my reviews (REAL NAME)

"Code Leader" is a book for developers who have been on a few projects and are ready to take that next step beyond just the "code" part of "coding." The book covers topics like when to build components vs. when to buy them, good testing practices, automating your build, and analyzing your code to learn where to improve it. Each topic is addressed at a reasonable pace, not miring you in super-low-level detail but providing enough information to get the point across.

As you read it, you'll find that much of it sounds like common sense, like some long-forgotten tidbit that you didn't realize you already knew. That's the strength of the book - bringing those things to light and showing you the benefits. The best example of this is the "Done is Done" chapter, bringing up the idea that sometimes when a developer says that a task is "done," there really are things left to do... and ideas on how to solve that so when someone says something is "done," all of the i's are dotted and t's are crossed.

At the end, the book brings all of the lessons together in a case study showing a developer performing a task from beginning to end and using the tenets described in the book. It's a good way to put everything into perspective and solidifies the concepts.

If you already practice things like test-driven devleopment and continuous integration; if you already know about the benefits of the MVP/MVC patterns (and use them); if you already know what dependency injection is and how it affects your testability; if you've got some nicely structured source control policies and do branch/merge per task (and know why that's good)... you may not get as much out of this book. You're probably already doing most of the stuff discussed and don't need to be sold a car you've already bought (so to speak).

Only two technical downsides to this book:

First, while the content could apply to any software development project in any technology, most of the tools mentioned and code samples are specifically .NET-oriented. That may be a little off-putting to non-.NET developers, but if you can get past that, you'll be rewarded.

Second, the text is abnormally small. I compared it to some of the other Wrox books I've got and there's got to be a two-or-three point size difference here, which makes the book lightweight but might give you a little eyestrain.

If you're looking for complementary books to this one, check out Coder to Developer: Tools and Strategies for Delivering Your Software by Mike Gunderloy. The two offer similar types of advice - ways to go beyond "just coding" and take your projects to the next level. While there are some overlapping topics, the two really are more complementary, each offering great guidance to help you sharpen your saw.

2 of 2 people found the following review helpful:

3.0 out of 5 stars Good, but not enough, June 26, 2009

By	Sean Feldman (Calgary, Canada) - See all my reviews (REAL NAME)

On my flight I had a chance to finish reading the book. It is a good source for ideas and concepts that any "solid" developer should employ on a daily basis. Topics such as TDD, build vs. buy, CI, choosing the right tool for the right job, contract driven development, and much more.

The book goes over subjects showing tidbits of everything, and could be probably expended and extended at least several times more. But then it would probably become "Clean Code" and "Agile Principles, Patterns, and Practices" clone, which author probably didn't want to create.

Overall, I liked the book as an introduction to so many "Alt [...]Net concepts in a single source. What I missed in this book is the human leadership in the code, the human-factor in code creation, the behavior and interaction between people that work on the same software. IMHO, code leadership is not only superiority in machine code, but also in the team environment.

5.0 out of 5 stars Develop better software now, September 14, 2008

By	Eric Kassan (Las Vegas, NV USA) - See all my reviews (REAL NAME)

Amazon Verified Purchase

This book does a fantastic job of presenting auxiliary processes in the software development lifecycle (processes such as unit testing, source control, continuous integration, etc.). It clearly explains the value in each process it describes, as well as various tools and options to consider. It also suggests aspects of software development itself such as the MVP (Model View Presenter) pattern, contract usage, tracing, and error handling. As with the processes, these aspects are presented clearly, objectively, and with common options and variations spelled out.