Great series of blog entries on DDD

Casey Charlton has a great series of blog entries on DDD (Domain Driven Design). The articles just keep on coming, and now he has made an ebook with all the articles. Great work, highly recommended.

Quality and the speed of development

Uncle Bob has written a post on the subject of quality versus speed.

I really like his point that speed in and of itself is not a success criteria. If the software you develop isn't quality software, it may (or may not) be faster to get the first release of the product shipped.

However, the speed of development for the remainder of the product's life may be heavily reduced due to the lack of quality in the design.

A good example of the opinion that speed matters more is when someone states that "we don't have time to write unit tests." Writing tests may take longer in the short run, but if done right, the quality of the software increases, which may even help get the release of out the door faster. At least, the quality of the code will improve.

In the upcoming book by Roy Osherove, The Art of Unit Testing, he deals with an example, where two teams in the same organisation implemented two similar features. One team wrote unit tests for their code, the other didn't. In summary, the unit testing team spent twice as long implementing the code. However, they were significantly faster integrating the code, and spent less time in manual test and bug fixing cycles. Actually, the team that wrote unit tests completed the feature in less time than the team that didn't. In addition, the number of bugs found in production was much lower.

The example in the book may not have been a very scientific study, but it shows that actions to increase the quality of the software may actually have the positive side effect of increasing the speed of development. Just remember that speed of development is not a quality in itself.

Fantastic quote on Java in the "good old days"

Java before the Convention over Configuration movement: "Java is a DSL to transform big Xml documents into long exception stack traces" (Scott Bellware, according to Jeremy D. Miller).

The Problems Of Reuse

Danny Lagrouw has commented on a blog entry called Reuse is vastly overrated by David Heinemeier Hansson. Basically, the conclusion is that often reuse is simply not worth the struggle.

I couldn't agree more. I have seen so many examples of efforts of trying (too hard) to "design something for reuse since reuse will save us so much time and money". Designing something to accommodate for future business requirements is extremely difficult since these requirements tend to be changing rapidly. You almost never know in advance the exact requirements of future uses of your code.

There are several problems with designing for reuse:

• Trying to design for generality in advance typically leads to overdesigning in a very non-XP way. This in itself might increase the costs of developing the general solution which can then be reused.



• There are always little twists which make two seemingly similar usecases different. These little differences tend to make the general design jump through loops in order to cater for the differences. It typically makes the general code less easy to read and maintain due to the handling of the differences and it definitely adds to the costs.


• Even when to usecases are similar when developed, I have seen many examples of business requirements "drifting apart", requiring the general code to adapt to the new gap between the usecases. Adapting to changes in one usecase may prove to be difficult as the changes apply to the general code. You need to be really careful with changes to the general code as it affects all the implemented usecases. And we're not even talking by the extra efforts in testing, since all the implemented usecases must be re-tested.
  

This is not an excuse for not creating quality design. I'm not saying that you should just copy-and-paste your way through the application - the DRY principle (Don't Repeat Yourself) still holds. However, I think it is important to really think carefully of whether reuse is feasible and find the right spots to reuse.