Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

TDD + DDD = BDD

Derek Comartin 1 Comment

Test Driven Development + Domain Driven Design = Behavior Driven Development

Although it isn’t anything new (coined 6+ years ago), it doesn’t seem to be as mainstream in terms of buzzword/awareness.  BDD is often referred to as TDD done right.  Meaning that TDD is about guiding design and not just about having a regression suite.  In DDD, there is the concept of ubiquitous language, which is about using the business vocabulary in the code base.

Dan North is the man behind BDD, check out his intro.

Or if you prefer video, here is a Google Tech Talk with Dave Astels.

Status Quo

Derek Comartin Leave a comment

In 2007 there was a movement in the .NET community dubbed “ALT.NET”.  A community was formed by individuals who believed there to be a “better” way from the tooling, frameworks, practices and principles provided by Microsoft.  The initial release of Linq to Entities (Entity Framework) was really a starting point for discussion since it did not support POCO’s and was not persistence ignorant.

ALT.NET was about challenging the status quo.  Although some might not be familiar with with the ALT.NET movement, you can thank it for helping the common practice of: Inversion of Control (Dependency Injection), Persistence Ignorant ORM’s, and SOLID principles.

So what happened to the community?  Was it a failure since it is no longer as active?  Or was it a success because many of the alternatives are now the “norm”?  I believe it to be both.

We need to continue challenging the status quo.  Individually and as a community.  Innovation and process improvement can only come from alternative thinking.  Have pride for the software you develop (Manifesto for Software Craftsmanship) and improve upon the existing practices.

Crappy Code Judgement

Derek Comartin 1 Comment

What’s the first thing most developers say after diving into legacy code?

It’s crap.  Giant plate of spaghetti!  What in the world was the person who wrote this thinking?

What’s interesting is we ask this question without really trying to answer it.  What were the objective and/or constraints to the person who wrote it? Without knowing this, you are making your judgement on unknowns.

Example #1: You have 30 days to complete.  This application is only assumed to be a temporary application.

Example #2: You have 30 days to complete, but don’t spend more than 16 hours.  This will be a legacy application.

Time and legacy are important objectives/constraints that were given to example #1.  Why practice programming to interfaces and create abstraction if you are writing throw away code?  If you know you are writing legacy code, maintainability is going to be more important.

We also often fail to acknowledge the technologies and practices that have changed.  Look back at your own code from 6 months to a year ago.  Do you catch yourself thinking:

I could of written this better by applying “X” pattern or following “X” principle?

Don’t be so quick to judge at first glance, unless you know all the objectives.