A few weeks ago I gave a talk entitled "Breaking the Software Death Cycle with Domain Driven Design" at the New York DDD Meet-up at Microsoft. Domain Driven Design (DDD) is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complex domains. My talk was both an introduction to DDD and a story about turning a large failing project around. As we analyzed triggers that enabled my team to be successful, I couldn’t help but notice the overlap in what DDD promotes in an organization and the core values of open-source.
But first, how does one identify a software death cycle in progress? These are my favorite symptoms:
- You feel the Sword of Damocles. Impending doom is in the air.
- The daily espresso venue attracts an increasing amount of people that laugh about how they are collectively failing. It's funny because it's sad.
- There’s a growing management pride in the act of shipping and not in the product itself.
- The output of the company is a fraction of the sum of individual capabilities.
- Engineers talk openly about other companies' hiring.
- More time is spent in Outlook than in core programming activities.
- Management promotes blind faith in open headcount.
An agent of change must first emerge to break the software death cycle. He will isolate a team of DDD researchers to collaborate on taxonomy. This is called "growing domain roots." This process is identical in nature to the beginning of any open-source project: a small group of individuals that trust one another will develop measurable output. In the case of DDD, this could be a wiki and in the case of an open-source project, early source code with developer “getting started” documentation.
DDD requires a clerk to do the bookkeeping. This individual helps focus discussions, encourages open collaboration and enables participants to grow and own sub-domains within the domain. All successful open-source projects also have the concept of a coordinator that knows how to exercise the right level of control and where to trust individual contributors to grow expertise in areas of the project.
Domain driven design anchors knowledge in core concepts, helping individuals in the room speak the same language. The development process is completely transparent and scales well through brown bags, presentations, open discussions and blog posts. This creates momentum and continuous success, which ultimately sparks the early fire under dying organizations.
Finally, the death cycle is broken when, after a few releases, your customers tell you that your team understands their business, and that your product solves a real set of problems. This same end-user validation is the reward of any enterprise open-source project, the ultimate satisfaction in the job well-done.
I believe that domain driven design and open source are simply tools that promote the core universal principles of openness, transparency, collaboration and meritocracy. Maybe these values are the key to any sustainable, scalable success?
2 Comments