I remember when, about a
decade ago, I was for the first time the lead developer of a team. It was
really exciting to be in charge of an entire application, with the unique chance to
start it from scratch. With the experience I got within the last years, now I can see that what I was
missing the most was knowledge about the process. At that time Agile concepts
were not popular and I felt room from improvement in testing, in building, in
sharing code, in communication… What I needed actually was a book like Code
Leader by Patrick Cauldwell. Short (200 pages) and straight to the point.
If you are reading the current post, there
are chances that you are used to learn by reading blogs. Then you are certainly
aware of Agile practices and with a bit of luck you are working in an Agile
team. But it seems to me that
the majority of teams are still not benefiting from the power of Agility. This
is especially true in the Microsoft
development sphere, where during many years Microsoft
did market the idea that building software was something rapid and easy, with
tools like VB and concepts like RAD (I don’t want to debate this particular point, see this debate here: At this point, I’d prefer Java developers over .NET developers by Dave Brion). Hopefully things are getting better now,
.NET is a marvelous piece of technology, Microsoft
discarded VB and fosters good practices through its tools and its communication.
you are a good coder
but still feel unsure about every aspects beyond the code (methodology,
communication, team management…), Code Leader is the book
you need. Patrick Cauldwell did a
good job at explaining what to do, but also the why you should do, the
intentions behind each practice. The book mainly covers:
- Testing: Test-Driven,
code coverage, kind of tests (integration/unit/functional…), test automation.
- Continuous Integration: Setting up a build server, how to harness build output and dashboards.
- Source Control:
Source Code Control System technologies and history, branching and merging
- Tooling: for
the concepts quoted above, but also for doing static analysis.
Cauldwell is an early adopter of NDepend
a .NET static analysis tool I am responsible for. The tool is praised in the
book. Patrick and his mate Scott Hanselman even took the time to do a poster
for NDepend metrics!
No matter this potential conflict of interest I sincerely do thing the book is solid and worth reading.
The last quarter of the
book is dedicated to explain advanced yet essential
coding concepts such as contract, dependencies management with low-coupling/high-cohesion,
Model-View-Presenter, tracing and error handling strategies. This part is in
the same vain as the rest of the book: you (the reader) are certainly a good
developer, maybe in charge of some other developers, and by reading this book
you will make sure you won’t miss any modern and efficient tenet to develop good
I would like to digress now on a detail of the book. At the page 150, Patrick explains that using static
contract through Debug.Assert(…) (and by extension through the .NET4
is a first step in implementing contract. Quote ‘an even better solution (…than Debug.Assert…) is to validate the input parameter of
methods explicitly’ by throwing exceptions if the validation fails. On this
particular point, I disagree.
- Debug.Assert(…) is contract,
- throwing exception on
parameters validation failure is behavior, code-defensive behavior.
Contract and behavior are
2 different things. Contracts are here to validate behavior. Contracts fulfill
the same need than unit tests: an automatic way to validate behavior
correctness. I take the chance to link here a previous post I wrote: Unit Test
Basically, this post explains that unit tests execution should not violate any
contract in the code, and then I focus on the particular problem: contract vs. parameter
- If a contract is
violated, there MUST be a bug somewhere.
- If a parameter validation
fails and then throw an exception, there MIGHT be a bug in the client code but
not necessarily. Imagine a program parsing some XML and retrieve integers values with
int.Parse(…). If the XML is corrupted, int.Parse(…) might throw an exception
and still, the program is not buggy, unless it is a bug to let such exception bubble-up
I took a chance here to
underline this contract/automatic
test/parameter validation/code defensive point which I think should deserve more attention in
general. Now it is time to go and read Code Leader. Btw, you can read Patrick Cauldwell’s blog here.