I wrote earlier about the apparent embrace of Domain-Driven Design (DDD) within the Interface21 team, the group behind the excellent Spring framework for Java applications. I have been thinking about why it is that Spring in particular would lend itself to the application of DDD.

I first expressed this during the review of the DDD track last Wednesday for the start of the conference. The escape from the productivity hit we all took with Java EE when Spring first began to be known was a big deal. The ability to have an layered, n-tier application that was testable out of the application container, with the ability to wire up a bean container’s contents via a straightforward XML syntax breathed new life into many a tired J2EE web application. Lines and lines of tiresome boilerplate code for DAOs were replaced with clean, small implementations that extended the appropriate Spring template. The effectiveness of our domain models were about the furthest thing from our minds. Why didn’t we immediately address domain modeling as soon as we had our sea legs with Spring?

I would say it’s analogous to not being that concerned about what clothes you are wearing when you are starving to death. Remember Maslow’s hierarchy of need from basic psychology in college? Few people whose physiological and safety need are not being met care that much about self-actualization. There are enough shops using Spring for there to have been two consecutive conferences dedicated to the technology. Spring is ubiquitious; that was the thrust of Rod Johnson’s keynote today. It has proven itself as a productive, viable foundation of enterprise Java applications the world over. Given that foundation, there exists the capacity to ask, “how can we now move to the next level of applying Spring in the best manner possible?” Domain-driven design answers that question.

Domain-Driven Design is not easy, and many, if not most, technologies actually impede the application of DDD. This is where Spring stands out among the raft of framework options. It has always had the intent of staying out of one’s way rather than attempt to infuse all of your code with its own prescriptive dogma (insert JSR of choice here). Spring stays out of your way, enabling the necessary insulation of your domain model. Since it is also Open Source software, there’s no need to bolster a revenue model by implementing any such ugliness in an attempt to ensure vendor lock-in. The Interface21 group is freed of that burden throughy their choice of Open Source, they are freed to pursue excellence in the code unfettered by a need to drive sales of the software. Since they depend on revenues through services, they are driven to make the best framework possible that will be of sufficient utility for more people to need training and consultation they provide. The model seems quite sustainable, and I wish them the best.

It seems ages since I last wrote. There’ve been wisps of motivation here and there, but mostly from odd topics or observations. A few things have contributed to that.

My enthusiasm about software development ebbs and flows. At a visceral level, I love the craft. The creative aspects balanced with architectural principles can be fascinating, and are almost always challenging for any problem domain beyond the trivial. However, the forces that wish to subvert and pervert the craft into a means of capital gain sap my energy. At times it’s downright depressing.

It’s not that I am against earning money by developing software or helping others develop it; by no means. That’s certainly how I provide for my family. The thing that totally turns me off is the agenda of most vendors and a certain contingent of programmers to portray software development as a deterministic, engineering process that is easily commoditizable — if only you buy product X or employ heavyweight, tool-centric methodology Y. That lie has held sway over most of the industry for far too long, at the expense of the craft and all who participate in both the creation and use of software.

Another thing that has robbed me of enthusiasm for close to a year now was an emotionally demanding contract with a challenging client. I had to spend many hours dealing with the effects of the engineering/commoditization myths and the unrealistic expectations and unproductive results they yield on projects. Grinding against that kind of friction left me with precious little emotional energy, and I wasn’t willing to spend that on writing and leave my family with even more of a withdrawn shell of a husband/father.

There have been a few things lately that have been a refreshing/renewing force in my software development enthusiasm. The first has been the practice of Domain-Driven Design (DDD). The frank attitudes about the rigors of good software development that best serves the stakeholders with flexible, extendible systems is so refreshing. An acknowledgement of development as primarily a creative process and less significantly an engineering process is a welcome message for me. I have begun collaborating with Eric Evans, author of Domain-Driven Design: Tackling Complexity in the Heart of Software and the person who first crystallized the concept of DDD as a practice. It’s certainly been invigorating and I am being challenged to develop my domain modeling and design skills to higher levels.

The practice of DDD in and of itself is great, but enthusiasm for a practice without a community of fellow enthusiasts/practicioners falls mostly to the realm of wistful “shoulds” and “oughts”. I am starting to see others, practicioners of the craft whose perspective I respect, also warm to DDD. Their reasons seem sound; they aren’t attempting to accrete another buzzword to their repository. For some it even comes at the expense of having to point out flaws in their own past approaches (or those of their employers) to software development. It is my hope that their candor will be rewarded and not punished.

I write this from the hotel lobby of the Westin Diplomat in Hollywood, Florida. It is the day before The Spring Experience, which is the first conference I have seen with an entire track dedicated to DDD. Eric and I attended the DDD track get-together last night with the Interface21 guys, and I am greatly encourage to see how the Spring Framework project has embraced DDD. It seems a natural fit, but more on that in a separate post.

An updated java-package will hit unstable in the next mirror pulse. Apologies to all for the delay; my discretionary time and that of my sponsors has been rather sparse for some time now. There are at least 9 bug reports addressed in the release. All users who have a JRE or JDK packaged by a previous version of java-package are encouraged to first remove their existing packages and then install an updated one generated by 0.28. Again, sorry for my low level of productivity for Debian, but paying my bills and being a new dad has been quite taxing (albeit rewarding) the past nine months.

So it’s finally OK to mention it now; Java has made it explicitly possible (read legal) to distribute the Sun Java JRE/JDK on a GNU/Linux distrubtion. The new license is for Java SE 5 on Linux only, called the Operating System Distribution License for Java, or DLJ for short. You can read the license in text or pdf form. The FAQ for the DLJ is also available in text and pdf. Heck, go through the README for the JRE and JDK while you’re at it.

So what does that mean? Well, GNU/Linux distrubtions like Debian can now package a Java runtime environment or Java development kit in their repositories. That was previously not possible due to restrictions present in Java licensing. Users still have to accept the Java SE 5 binary code license that is totally not free and has the same restrictions Java has always had, but this at least makes packaging and supporting Java less painful for distributions.

Sun is coordinating the efforts via a java.net project, jdk-distros. This is an unprecedented level of cooperation from Sun with external parties in anything related to Java. I consider myself fortunate to have been a founding member of the project. It has been a pleasant and refreshing experience to meet a few optimistic and forward-thinking people from Sun who have a keen interest in Free Software; a big thanks to Simon Phipps and Tom Marble. I was encouraged that they allowed our contributions to be covered under the MIT license. If you would have told me that a month ago I would have laughed at you.

The Debian announcment should be posted on the debian-devel-announce list today. I am sure this will draw both praise and ire from the Debian community. That’s cool, though; the rich diversity is part of what makes it such a vibrant organism.

Code Quality, Mentoring, Enterprise Software Management, and mixing Java and .Net carried the day. The format we adapted today was excellent for these topics; we went in roundtable fashion and each participant shared what they do to ensure quality and mentor. After hearing Ben Geyer talk about XRadar, I definitely have to get that set up on my projects at the client site. Someone mentioned the idea of “a build breakage is a line stoppage”; I think it may have been Andrew Moore. That was an interesting concept and hearing how it was carried out in Andrew’s instance was beneficial. Here are the points I shared about quality:

In my consulting/development work

• Reiterating the “sign your work” principle of Pragmatic Programming
• Discipline as a necessary quality; the ability to do what is required for good software yet isn’t fun, intriguing, or stimulating to a narrow attention span
• Use a world-readable version control repository
• Publish the Javadoc and unit test reports to the project website
• Use Checkstyle to enforce conventions
• Use peer reviews for code releases that push to production
• Solid unit/integration/functional testing

This was probably the most public setting where I have shared my observation on unit testing, probably my most original (and distinctly Southern) perspective on quality:

Unit tests are like toilet paper; they have it everywhere I go, but the quality varies widely from place to place.

In my Debian work

• Domain-specific code checkers, lintian and linda
• Using IRC and Nopaste for remote collaboration