Laziness Driven Design

I have become fanatical about writing unit tests for every method on every class, regardless of how trivial that method first appears. ( "But it's just a getter!" )

This leads to an interesting laziness driven feedback loop. Here's what happens:

I am implementing a feature, and think that the shortest distance between two points, is to add another dependency onto one of my classes, but then I realize that this new dependency would further complicate all of my tests, requiring large changes. Ugh! I don't have time for sweeping changes to my test suite.

So, in my laziness, I skip over the initial, obvious solution, think a little bit harder, and come up with a truly simpler solution.

The PO-STAR Movement

In the past year, I have seen an increasing number of "Plain Old *" abbreviations:

• POJO - Plain Old Java Objects
• POCO - Plain Old CLR (.NET runtime) Objects
• POX - Plain Old XML

At this point, I think it qualifies as a crypto-movement, and the clue to the genesis of this movement is in Andy Smith's "Why Frameworks Suck."

Frameworks hurt sharing. I’d really like to give you this fork Jimmy, but you’re gonna need a knife and plate to use it.

The alternative to PO* is to buy into some framework, which inevitably prevents code reuse as your classes become riddled with framework junk.

You know a library is really a framework when:

• It requires you to derive your classes from some library class.
• It requires you to use their main() function.
• It requires you to use their Application class.
• It requires your classes to depend on some third party library.
• The setup() and teardown() methods of your test suites become really complex.

Nearly every time that I have written framework-like functionality into an application, I have found that I was able to factor it out in favor of simple library classes that are themselves PO* objects.

I Heart Python

I have been playing around with Python at home, developing a simple web application, and I just wanted to say that I think that Python is awesome.

Fear of the Domain Model

Did you ever notice that many programmer's tend to shy away from developing a domain model?

This is a pretty reasonable reaction. We want to exploit our strengths, and leave the domain to the domain experts. We want to continue to improve our knowledge of computer technology, because this translates into a personal asset.

I think that the ability to elicit domain knowledge from a domain expert and convert this into a viable domain model is a more important skill than the knowing the latest technology that your tools vendor is trying to push at your CIO.

A rich domain model is truly fertile ground for developing applications, and building working, valuable applications is way more important than extending one's knowledge of the solution domain.

The Garden

Originally uploaded by Jennifer Dunne.

This is picture of a flower in my wife's garden.