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.