Seven Signs why Santa Claus isn’t agile

As a kid, christmas was extreme magic.
Every year again, while there was a big scrum under the christmas tree, i’ve wondered how Santa’s capable to serve all kids in a single night.
Looking back, there seems to be only one conclusion: it’s crystal clear – Santa’s a real agile dude. In fact, it seems that he’s a Master in clearing impressive, huge backlogs and indeed knows what a real sprint is …

But take a detailed look behind the facade – there are some signs that Santa might not be that agile guy he seems to be at first sight …

Test Driven Development and Design By Contract – friend or foe?

in this post i’ll try to answer a legitimate question, relating to a comment due to my last statement that interfaces are poor contracts: why do we need contracts (in the sense of invariants, pre- and postconditions) when we’ve got unit tests right at hand, that could also test the stated conditions?

in fact, it’s very tempting to see unit tests as an all-embracing instrument to check and show that a class will behave correctly, making contracts kind of unnecessary.
i’ll try to show you that unit tests (as an instrument for test driven development) and contracts (as an instrument for Design By Contract) indeed share the same goals but aren’t competing techniques, rather than methods that could complement each other.

Why interfaces are poor contracts

what’s an interface for?

ok, we can achieve loose coupling and a higher degree of abstraction by shielding clients of a service or component from concrete implementations, that allows us to be very flexible in changing the underlying implementation. We also can describe flexible, independent type systems without the restriction of single class inheritance by having classes that might implement more than one Interface, playing multiple roles in different areas of one or more applications.