Thursday, February 28, 2013


In his presentation "Designing For Rapid Release" (slides) Sam Newman points out an ugly fact that we often try to ignore: SOA and DRY are to a large extent opposed forces.

Of course this is not a new break-through discovery and I guess it is also nothing new for most battle-proven enterprise developers. But I also have the experience that in most SOA projects this topic is treated like the crazy uncle in the attic: You don't talk about it and you certainly don't plan for it.

The result is usually a schizophrenic feeling: The architecture postulates nice decoupling, but in reality we end up with the feeling that we are not doing it right: either we are using shared logic in several services which negates idea of decoupling or we have a lot of code duplication.

In the presentation Sam illustrated this conflict with two services that share a common domain model:

Screen Shot 2013 02 17 at 4 53 06 PM

In the above picture, since service A and service B are both using a common model from a shared library, they get tightly coupled. On the other hand managing the development and releases of the shared library all of a sudden gets much more complicated under the premise that service A and service B should be decoupled.

He further brings the incompatibility of SOA and DRY to the point with the following quote:

Ending up with tightly bound services because of code-reuse is significantly worse than to copy & paste that code.

I like that Sam makes the conflict between SOA and DRY explicit. Not ignoring this fact is the first step to objectively balance the tradeoffs and to honestly plan how to deal with the drawbacks of either approach.

Friday, February 15, 2013

Quotes of the Week: Developer Testing

Nothing makes a system more flexible than a comprehensive suite of tests! Far above good architecture and good design!
- Robert C. Martin,
Oredev 2008 Keynote
We have as many testers as we have developers. And testers spend all their time testing, and developers spend half their time testing. We're more of a testing, a quality software organization than we're a software organization

TDD is a discipline for programmers like double-entry bookkeeping is for accountants or sterile procedure is for surgeons..
Tests should be made a first-class citizen and treated like any other feature.

TDD, BDD and other high-ceremony techniques are not recommended for startups! Code is not important in the beginning!

I see TDD as a valuable and important development technique, but there are contexts in which it shines and others in which it is a hindrance.

Insisting on unit tests won't make those unit tests valuable.

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence.

If I don’t typically make a kind of mistake, I don’t test for it.

Testing is overrated!

A survey of all the studies on TDD has shown that the better the study done, the weaker the signals to its benefit.

Thinking you can improve quality by doing more testing is like thinking you can loose weight by weighing you more. […] If you want to improve your software, don't test more; develop better.

- Steve McConnell, Code Complete

You cannot inspect quality into a product. The quality is there or it isn't by the time it's inspected.


Much of the essence of building a program is in fact the debugging of the specification.


Related Posts Plugin for WordPress, Blogger...