Book Review: Code Leader by Patrick Cauldwell (+ a digression on contracts)

Posted by Patrick Smacchia on May 17, 2009

 

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.

 

If
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
    strategies
  • Tooling: for
    the concepts quoted above, but also for doing static analysis.

 

Disclamer: Patrick
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
software.

 


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
contract API)
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
vs. Debug.Assert().
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
validation.

  • 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.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • John "Z-Bo" Zabroski

    Also, if the “size” of Robert Cecil Martin’s book intimidates you, he has a much shorter book called Clean Code that is vastly superior to Code Leader in every way imaginable.

  • http://z-bo.tumblr.com John "Z-Bo" Zabroski

    I didn’t like the book. The explanation of “why Inversion of Control matters” was very weak and frankly incorrect. Much better explanations on software design are provided by Robert Cecil Martin’s Agile Software Development Principles Patterns and Practices.

  • http://www.eqa.dk Kaj Bonfils

    Finally… I have been looking for a book covering these topics for a long time. I have even considered writing the book myself… I will buy it, read it, and hopefully it will save me a lot of writing.

  • http://http:dotbloat.microsoft.com Mark Gordon

    I’m not on the bandwagon for UNIT testing. This entire concepts has been tried numerous times before and never many any real in roads to DOS applications

    Here are just some of the issues with unit testing.

    1) The testing is only as good as the script itself.
    2) Programmers waste time fixing bugs that an end user would never catch
    3) Just because your module passes the test doesn’t mean the UI or the results sets for that matter is what the end user wants it only means the code runs as good as the script.
    4) Given the stability of many of microsoft’s new technology and vast array of implementation/usability issues and BUGS including those found in VS 2010 that is a testament of just how inefficent automating testing is.

    I think it would be in developers best interest to stop writing spaghetti code and return to small less complex modules, properly subclass and seperate tiers then waste time with automated testing Unforunately given the direction Microsoft is taking with CRAP technologies like silverlight and WPF where markup spaghetti code is driving the UI and the application and we can’t forget about the lack of N-TIER database technology in VS, Microsoft needed some method to fix their bad implementation of these so called frameworks and paradigms so hence we are being returned to the days of spaghetti code and automated testing. With this spin that this is some great new breakthrough technology. Actually isn’t that what MSFT did with MVC and MVP make that sound new when really it has been around forever the only thing new is really MSFT decision to copy it?

    Have to love the marketing guys at Microsoft they sure know how to fool the hobbiest. I think the new catch phrase for visual studio should be how far back in time do you want to develop in today as that is where this Microsoft is taking us.

  • http://www.cuttingedge.it/blogs/steven Steven

    Patrick,

    I agree with you that a Contract is a requirement and it must not be violated at any time.
    I also agree that we want have as much as possible automated tests to prevent bugs from happening during production. I agree that we should program as defensive as possible. Last but not least I agree with you that we miss the absence of contract (Spec#) in our language and we need (more) compile time checking to fight bugs.

    However, I’m a bit confused when you say “Contract is a requirement that MUST not be violated at any time” but also advocate Debug.Assert, because -as you know- release / production builds do not contain Debug.Asserts calls (C# compiler removes them during compilation). For this reason I throw exceptions. I know they can be caught / suppressed (and I’ve seen developers do horrible things by catching exceptions), but they will normally bubble up the call stack and will eventually be logged (by using a logging framework). When there is a bug in my code, I want that code to fail and not silently continue in a possibly corrupted state.

    I don’t understand why you compare Debug.Assert with theorems, because you can’t prove anything by using Debug.Assert. You can’t (automatically that is) prove they never fail. That’s -I believe- the whole point about Code Contracts. It uses a theorem prover (boogie) that checks your asserts. I agree with you that a contract is a contract, but I don’t understand why you differentiate between debug and release builds. Okay, in some (corner case) scenario’s I understand you don’t want to check them, because of the performance penalty, but in my experience that penalty is neglectable in most cases.

    As you said, a contract is a contract. When there’s a bug, we want to know AND we want to fix it. So again, why are you using Debug.Assert? I’m confused.

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    >I find I use asserts less and less and try to use unit tests more and more.

    I found both approaches very complementary, this is why I activate Debug.Assert(…) while running unit tests with TestDriven.NET.

    >Its pretty rewarding though when some assert I’ve long forgotten about fires and says “oh you have a bug here it is.”

    Completely agree, bug discovery for free :o )

  • fschwiet

    One reason to prefer asserts over exceptions is that someone might catch and handle an exception, hiding the bug. This might make sense in production but it in a development environment you want the thing to blow up so it gets fixed.

    I have no problems with leaving asserts in the release code, there is debate as to whether or not they should be removed in the first place. I find that typically debug asserts are not a huge performance hit. They can be, but that is rare.

    Whether to assert or not in release mode, (and correspondingly if an exception is better than Debug.Assert()) is a long-standing disagreement amongst developers I would not try to resolve once and for all. Learn from both sides :) then when you’re on a project choose the approach thats consistent with existing code first.

    I find I use asserts less and less and try to use unit tests more and more. Its pretty rewarding though when some assert I’ve long forgotten about fires and says “oh you have a bug here it is.”

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    >that debug.assert is a behavioral delta between debug and production builds.

    Absolutely not, Debug.Assert(…) nor any Contract 4.0 API should change the behavior. If it does then it is a bug like if someone would write:
    Debug.Assert( here a method that returns a bool and that has side-effects )

    >Yeah, life would be rosy if I could just convince clients not to change their minds, or convince them that timelines will need to flex when they do, but that’s rarely the case.

    Sure, nobody in charge of a Fx can control what clients are doing with it. This is why exception on wrong inputs is needed, this is a defensive pattern against wrong clients usage. Basically you define the following behavior: if my client gives me a null reference, they’ll receive a NullReferenceException. You can call this behavior a contract between you are your client but this is still not DbC.

    As I explained in the entry…

    http://codebetter.com/blogs/patricksmacchia/archive/2007/10/10/unit-test-vs-debug-assert.aspx

    …Debug.Assert(…) is much more suited than exception when it comes to internal & private code, where you control usage. If I control callers, then I can guarantee at development/test time that a particular param is not null for example. But it is much more powerful than just defensive param input validation. I can control basically at any time (during development/test time) that any reachable state is valid (loop invariant, class invariant…). Such a power can only comes at significant performance cost, validation is often very tricky because states are tricky + the more often validations are done, the more likely they’ll detect a corrupted state. These validations are then not relevant in production code. But at least these validations increase a lot chances to discover my own bugs (not client bug) early, before production. This would be silly to not use such a powerful mean!

  • Steve Py

    I’ve already covered this. Using an exception is *not* defensive. Inspecting parameters and attempting to mitigate possible invalidity of the pre-condition (I.e. setting default values or conditional substitution) is defensive. Nothing that I’ve said is about using exceptions to “handle” invalid pre-conditions. They form the contract, and as an added benefit they improve the behavior of the application in the event that a slipped requirement reaches production. It’s not about elaborate try/catch structures to capture & try and handle rogue behaviour. It’s merely about elevating the contract checks into a more meaningful form *should* they reach production.

    I know this goes well beyond parameter validation, and it’s real value is enforcing expected behaviour in subclasses. Microsoft argues that neither exceptions nor debug.assert are particularly well suited to enforcing contract. I’d defend that exceptions are no worse at enforcing contract than debug.assert.

    DbC is a technique to attempt to deliver “better” code. Nothing, and no-one delivers “perfect” code. My whole point about why I believe exceptions are preferrable to debug.assert, and why I’m not in favour of contract enforcement solely in the realm of debug builds is that debug.assert is a behavioural delta between debug and production builds. As I’ve learned about system testing techniques, the combinations and permutations of possible inputs and outputs within reasonably simple applications can be astronomical. Testers aim for the “best bang for the buck” but ultimately it’s the business that determines the most valuable permutations, and the simple fact is that they rarely know (wet finger in the air) 75% of these ahead of time. The remaining 25% or more shift through the life of the enhancement/product. Pre-release exclusive contract will catch regression issues, but it has no value to clients for issues that aren’t sufficiently discovered or tested before release to production. Yeah, life would be rosy if I could just convince clients not to change their minds, or convince them that timelines will need to flex when they do, but that’s rarely the case.

    I do concede, however, that contract solely in Debug would be preferrable in situations where performance is paramount. In 95% of the projects I’ve worked on, usability is paramount. I don’t design systems to predict and solve their own problems, I design them to give clients tools to keep things running smoothly in the event an enhancement doesn’t go 100% according to plan.

    I doubt I’d ever agree with you on this point. As for the people I work with, I value that they have brains of their own. If they see ways that this will be beneficial I’m all eyes.

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    >I don’t give a crap whether you want to argue this difference is contract vs. behaviour

    All the problem is here actually. What you are talking about is code defensive behavior. I never said it is a bad practice, it is indeed not possible to do without when you are publishing a framework.

    But because you think that contract is the same thing as code defensive behavior, then you are missing an opportunity to learn something that you don’t know, something that you could benefit from: Design by Contract.

    And because of your close attitude, all your guys will never have a chance to learn it as well, very bad thing :o /

  • Steve Py

    Bugs aren’t magical, but “requirements”, the things you base contracts on, aren’t 100% complete and static at any point in time on real-world projects. Requirements and expectations change, often when code doesn’t.

    Contract is about pre-condition and post-condition assertion, it is still served equally well with exceptions, with the “added” benefit of that there is no risk of “behaviour” changes.

    Why would I throw NullReferenceException manually? I throw ArgumentNullException with the name of the argument.

    What’s the difference? Well, on one hand in production you can end up with a client that has a handled/unhandled exception that states: “Value cannot be null.” or an exception that states: “remainingStockLevel was not provided.” I don’t give a crap whether you want to argue this difference is contract vs. behaviour, my argument is that it “satisfies” contract while at the same time reinforcing helpful behaviour.

    Can you test every pre/post condition? You can probably test every one you “know about”, but IMO (there’s my “opinion” again) good practice = ensuring customers at least have something useful in the event of an unexpected bump.

    As for my “first reaction”, that’s not my first reaction, that’s just my leading statement, and my “opinion”. The people that write stuff like this are a hell of a lot smarter than me, and maybe it’s a practice they can justify and convince people that it works. But that doesn’t mean they make no mistakes, and it certainly doesn’t mean they have “initially bug-free code.” (here’s my “opinion” again, *that* is the stuff of magical fairy-dust.) Many of the major cock-ups in the world are brain-childs of bright people. Only hind-sight is 20/20.

  • http://www.NDepend.com Patrick Smacchia

    >Bugs happen, and they happen based on stuff that you, I, and even the client “didn’t think of ahead of time”.
    I don’t agree: bug don’t happen magically, there is no such thing as dusted code. Bugs happen only when initially bug-free code evolves. This is why contract are so useful: they let detect regression bugs early at development/testing/refactoring/evolution time.
    And also does throwing explicitly NullReferenceException in production code could help in anyway?
    Wouldn’t the CLR send this exception anyway when the code try to use a null reference?
    Do you write a unit test to cover each NullReferenceException sent manually?
    Just the fact that an exception is thrown and a unit test must be written to get 100% coverage by tests isn’t the crystal clear proof that what you are talking about is behavior and not contract?

    Read carefully and understand the following sentence extracted from the wikipedia note and more importantly, stop confusing junior programmers you are in charge of.
    >The contract conditions should never be violated in program execution; thus they can be either left in as debugging code or removed from the production version of the code altogether for performance reasons.

    Your first reaction against this beautiful piece of mind was:
    >IMO this is horse-hockey-pucks.
    It is like if guys that invented Design by Contract (Bertrand Meyer and co) suck, like if they are writing stupid stuff. It is like if the thousands of reader of this Wikipedia entry on DbC accepted so far a flawed idea. It is like if you know what is contract, not them.

  • Steve Py

    Using an exception is not defensive coding. Adding code to attempt to handle every conceivable call (I.e. assigning a default when provided a #null) is an example of being defensive.

    The only difference between using Debug.Assert and an exception is that the contract check via debug.assert is only performed prior to release. I have read the DbC entry on Wikipedia and the part that really leaves a sour note is:
    > “The contract conditions should never be violated in program execution; thus they can be either left in as debugging code or removed from the production version of the code altogether for performance reasons.”

    IMO this is horse-hockey-pucks.
    Bugs happen, and they happen based on stuff that you, I, and even the client “didn’t think of ahead of time”. Just as a unit test should not be relied upon to test all pre-conditions, I don’t believe using debug-only contract checks is a good solution to enforcing a contract. The idea of removing the contract validation in a distribution borders ignorant or arrogant.

    The biggest fiend in software development is NullReferenceException. It will be a glorious day once we get non-nullable reference variables, but until that day comes, I’d MUCH rather throw (and catch) an exception that tells me that a required parameter/pre-condition is #null rather than naively expect that my unit test suite or even integration tests pick up a Debug.Assert condition before that code makes it to production and vanishes to the obscurity of a bug or some meaningless error message hard-fail exception to the user and a trip through the call stack hunting down a null value. (Sorry for the run-on sentence but this is just the kind of wind needed to hunt those buggers down.)

    At least with an exception to the effect that something like a specific required value wasn’t provided gives the client/support information about what puck just hit the fan and they can hopefully devise a work-around before a fix is delivered. A validation exception that says something to the effect of “remainingStockLevel was not provided” is of a hell of a lot more use to clients than “Value cannot be null.” or “Input string was not in a correct format.” If my contract states that the value of remainingStockLevel passed in needs to be provided to update the stock level, then a Debug.Assert and exception perform the same task. The exception is a useful safety net should whatever mechanism I rely on to assert my Contract not pick it up.

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    Steve, you wrote:

    >Contract validation is better served by exception because the behaviour pattern is identical between debug and release builds.

    and I rewrite:

    >Contract is a requirement that MUST not be violated at any time, this is not related to development/test/production time at all.

    Please read carefully this blog post where I concretely expose an example of exception vs. Debug.Assert(), or if you prefer, defensive code vs. contract:

    http://codebetter.com/blogs/patricksmacchia/archive/2007/10/10/unit-test-vs-debug-assert.aspx

    And I really hope you’ll get the point: evangelizing junior developers to favor exception over Debug.Assert(…) and naming such defensive code pattern ‘contract’ as you do, is a bad bad professional mistake.

    Read this also:

    http://en.wikipedia.org/wiki/Design_by_contract

    >When using contracts, the program code itself must never try to verify the contract conditions; the whole idea is that code should “fail hard”, with contract verification being the safety net. DbC’s “fail hard” property simplifies the debugging of contract behavior as the intended behaviour of each routine is clearly specified.

  • http://www.AnalysisUK.com Stephen Harrison

    Thanks Patrick.

    I’ve picked up too many projects that have had one or more evil “#if RELEASE” sections of code in them making me a little nervous that the unit tests would not be testing a code base representative of the release product, hence my concern about testing debug builds to catch the debug.asserts and testing release code as well (although that then wouldn’t catch the debug.asserts).

    I know the answer is to try and remove the #if’s in the first place but sometimes that can be a lot more difficult to encourage the team your working with that it’s a good thing than you would hope for.

  • Steve Py

    Hmm.
    >Stephen, we run tests only on Debug build. There MUST not be any behavior difference between Debug and Release build, else it would be really really evil.

    Hmm, the trouble with Debug.Assert() is that it is different behaviour between Debug & Release. Contract validation is better served by exception because the behaviour pattern is identical between debug and release builds.

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    >Out of interest do you run your automated build unit tests as debug only to catch the Asserts or do you run the unit tests for both Debug and Release?

    Stephen, we run tests only on Debug build. There MUST not be any behavior difference between Debug and Release build, else it would be really really evil.

    An important point explained in the post…

    http://codebetter.com/blogs/patricksmacchia/archive/2007/10/10/unit-test-vs-debug-assert.aspx

    …is that running unit test should not break contract: it would mean that unit tests provoke corrupted states. There is no point in testing how code behave in case of a bug, better having a bug-free strategy where each known bug is corrected ASAP.

  • http://www.AnalysisUK.com Stephen Harrison

    Thanks for writing up the review, I’ve been wondering about buying this book for sime time. I’ve ordered my copy now.

    Out of interest do you run your automated build unit tests as debug only to catch the Asserts or do you run the unit tests for both Debug and Release? (for the case where you havn’t split the debug/release build between 2 build machines/tasks).

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    Steven another way to explain things, you write:

    >but it’s a ‘debug only’ contract, which is not strong enough in my opinion.

    Would you say a mathematical demonstration of a theorem is not strong enough? A demonstration is valid or not valid. A theorem is true or false.

    The same for contract: the code is correct or not, a contract is valid or not valid. Contract are here to help check correctness. Correct code means bug-free code in the context of the program specification.

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    Steven I disagree with your opinion. Contract is contract, you are talking about coding defensively. If a contract is broken, there is a bug somewhere FOR SURE. This is the point I want to underline in the post especially because it is subtle, yet essential (and often misunderstood).

    Contract is a requirement that MUST not be violated at any time, this is not related to development/test/production time at all. It is better to check contract only at development/test time just to not consume performance at production time but it is the only reason. I see contract as code scaffolding that you can remove at production time.

    You wrote:

    >Would it be bad if an assertion fails in production and should we (be able to) fix it?”. If the answer is “yes” (and it almost always is), Debug.Assert is not the good solution.

    It is like if you don’t trust contract. Of course the answer is ‘yes’, it is really bad if an assertions (i.e a contract) would fail in production: it means there is a bug somewhere.

    Coding defensively then is just an attempt to deal with the consequences a bug, but it is hopeless because a bug provokes unexpected/corrupted states. The only hope here is that the client sees and report a problem. This way you can investigate and fix the bug for the next release to guarantee that the contract won’t be violated anymore.

    Contract.Assert (.NET 4.0) is just a syntactically more elegant way than Debug.Assert to declare contract, it is not ground-breaking. This API is welcome, it will help promote contracts + have more elegant code + open the door to more intelligent tools like Pex. But from my point of view, the absence of contract in the language itself (especially about non-nullable) is still THE major flaw of the .NET platform:

    http://codebetter.com/blogs/patricksmacchia/archive/2007/07/25/i-want-non-nullable-types-in-c-4.aspx

  • http://www.cuttingedge.it/blogs/steven Steven

    I always advocate against the use of Debug.Assert. I teach the developers I work with to throw exceptions. Debug.Assert might be contract, but it’s a ‘debug only’ contract, which is not strong enough in my opinion. I hardly ever saw assumptions that were fine to suppress in release mode. I always ask myself and other developers: “Would it be bad if an assertion fails in production and should we (be able to) fix it?”. If the answer is “yes” (and it almost always is), Debug.Assert is not the good solution. Contract.Assert (.NET 4.0) however is very welcome change. I’m looking forward to Code Contracts.