Domain Driven Design Anti-Patterns

Posted on by
3

[Note: I was going to call this post How to Fail with Domain Driven Design, but that just sounded too pessimistic.]

I’ve been developing business applications on the Microsoft platform since the mid 1990s. The years since then have involved a continual process of learning to be more effective in architectural approach. Along the way, there have been key points where I made leaps forward. Two such examples include object-orientation in the 90s and my first Web service in 2000 (anyone remember SOAP Toolkit2?).

Each of these leaps forward also came with some initial stumbles as I grappled with the promising new approach. Pushing the envelope of productivity means trying new things. New things always create risk. Software is hard. The path of progress in software is never a straight line (unless you are creating commodity level software). However, stumbling when taking on new approaches can be minimized if you learn from other peoples mistakes instead if just your own.

Another big leap forward for me started with my reading of Domain Driven Design in 2005. Since that time, I have been putting DDD principles into practice. I have learned a lot-much of it by my own mistakes. What I offer here are some concrete examples of mistakes I made. I’ll show the mistake I made and how I later fixed it so you can compare and contrast the before and after. Sometimes I learn a pattern best by seeing examples of its anti-patterns. I hope these articles will help you create better software and add to the growing awareness of DDD.

  1. Not accounting for command and queries as separate concerns.
  2. Not getting the whole team educated on DDD early enough.
  3. Not taking bounded contexts seriously.
  4. Allowing implementation decisions to drive the domain model.

The above list will serve as the table of contents for the series. I’ll enable the links as I write the articles. I’ll probably add an article or two to the list as I go.

Free Your Data, and UIs are Free

Posted on by
Reply

This video describes how the Massachusetts Department of Transportation began publishing real-time bus arrival data and within two months there were six compelling applications available that harnessed that data.

Joshua Robins of the Massachusetts Department of Transportation

This shows that if you make your data available, there are legions of developers willing to build applications on various platforms. Massachusetts could have spent months building a lame Web site and then making the data available. By making the data available first, they didn’t need any UI at all.

It’s easy to see how this can work with public data. I believe this same principle works inside the enterprise. If we build our line of business applications to publish their data in open formats, anyone can build the applications that display that data to users in whatever formats users need.

HT: Jack van Hoof

Why Software will Always be Hard, Part 2

Posted on by
Reply

My last post on Why Software will Always be Hard got me thinking about the implications for the software team that wants to create value (i.e., be worth more than they cost). If the bar is constantly being raised on what is considered commodity, then the software team creating value, must continue to get better in order to continue to deliver more next year than they did this year.

Innovation 

In the graph above, I’ve depicted the drive toward higher and higher expectations as the blue line. The green line represents the delivery level of the  high-performing team. The space between the two lines represents the value created by that team. In order to continue to deliver value, it must continue to innovate to deliver more for less.

While the commodity line drives steadily upward, the innovation line sometimes plateaus and may even drop prior to new increases. Innovation always brings risk and sometimes they will reduce your output before improving it. This is why even the high-performing team must continue to look for and expect improvements in its processed and technologies.

Why Software will Always be Hard

Posted on by
Reply

There is a funny thing about the software business… people expect that building great software should be getting easier. On the surface, that seems like a reasonable expectation. Software is a maturing field. The tools and technology are improving rapidly. The money to be made is attracting bright and capable people. So, why does making great software seem just as hard as it ever was?

There are two market forces working together to ensure that making software will be hard for a long time—at least as long as software will be worth building.

Market Forces

The first force in play is the fact that as soon as technology improves to allow us to build today’s software more efficiently and effectively, the market will raise the expectation of what it will pay for.

The second force in play is that the world is flat. This is especially true in the software business. Unlike automobiles and silly bands, software incurs no shipping costs; so the market of suppliers is truly global.

Result

Those two market forces mean that as soon as a certain level of software functionality becomes easy to provide reliably (think on-time with no bugs), there is such a large supply of providers that no one will pay enough for that software to make a company profitable. Any software company (or department) that wishes to make a profit is going to have to provide something more: better integration to more complex systems; unseen functionality levels; innovative new platforms;  more immersive experiences, etc.

That pushing of the envelope means that software will be hard as long as there is any money to be made in it. My dad used to say to me “Eric, if it was easy, anyone could do it.” And if anyone could do it, it hardly ever pays well.

Teamwork Is an Individual Skill

Posted on by
1

I was intrigued by this interview with Christopher Avery about responsibility on agile teams at InfoQ. Intrigued enough to go download and read his book entitled Teamwork Is an Individual Skill: Getting Your Work Done When Sharing Responsibility.

The premise of the book is that, contrary to conventional wisdom, not only is there an “I” in team, but teams are constituted by nothing more than a bunch of “I”s. If none of those individuals takes responsibility for the team’s success, then no one is taking responsibility.

Whether it be the development team at work, the elder council at my church, or even my family, it seems there is virtually no area of life where my personal success is not dependent on the success of a team. Learning to take more responsibility for the success of those teams seemed like a good idea.

I found that the book could have used a good editor to tighten up some of the writing, and the formatting (at least on the Kindle version) was confusing at times; however, there was enough food for thought in there to make it worth the read.

Here are a few highlights to give you some flavor of the book…

Avery coins the term TeamWisdom, which he defines as follows.

TeamWisdom refers to all the individual mental skills and behaviors that lead to highly responsible and productive relationships at work. The idea is based on my definition of “team”: A team is a group of individuals responding successfully to the opportunity presented by shared responsibility. Thus someone with TeamWisdom takes responsibility for ensuring that the group rises to the occasion, and in the process, makes sure his own work gets done and done well.

Avery makes an important distinction between accountability and responsibility

…accountability can be assigned, but responsibility can only be taken.

Accountability and responsibility are not mutually exclusive. In fact, they are extremely complimentary. It is time for each of us in the workplace to take responsibility for relationships as well as accountability for deliverables, and to engage in the conversations that build productive relationships at work.

Avery makes the astute observation that if each team member acts in his own self-interest, then it is important to learn what motivates the other team members and assure that their interests are aligned with those of the team and with your interests. If your interests cannot be aligned, then you should withdraw from that team.

Once you understand your team members interests, it is in your interest to see that your teammates reach their goals.

The great philosopher/inventor, Buckminster Fuller, taught that the best way for one person to win is not by making others lose, but by making others win too. He taught from the 1940’s until his death that the more people a person helps to win, the more people that person can expect will help her win. Fuller’s teaching was in the forefront of a growing body of literature about the power and humanity of “servant leadership.” Being a servant leader means helping one’s followers become successful, instead of expecting followers to serve one’s personal success.

He then gives the following challenge in the Personal Challenge section that is included in with each TeamWisdom principle.

Do your partners and teammates provide you with access to their thoughts because they experience you as a person who helps them achieve their goals? Listen carefully to your associates to learn what is truly important to them. Check in with yourself to determine your level of commitment to them. If this level of commitment is low, ask yourself why. If it is high, ask yourself how you are willing to help. Then offer that help.

Avery talks about collaboration and includes valuable insights like this:

Most people find it much easier to grant a favor than to ask for one. However, people with TeamWisdom know that asking for a favor actually grants the other person a favor. Asking for a favor communicates to the other person that they are important to us, that we depend on them, and that we are even willing to owe them one. People with TeamWisdom understand that the person who asks for the first favor sets the tone for the collaboration.

Here is an example of Avery’s insight on the effect unmotivated team members:

Is the team leader the most powerful member of your team? Is the most inspired member the most powerful? The smartest member? Nope. None of the above. Like it or not, the most powerful member of your team is the one who cares the least about your team’s task. Sorry, but that’s the truth. The least-committed member of your team is the most powerful because his lack of commitment establishes a low baseline to which other
team members may fall. The success—or mediocrity—of your team likely will be determined by him.

Read the book. Take responsibility for the success of your teams, whether you are the leader or simply a contributor.

Shifting from Scrum to Kanban

Posted on by
1

My team had been following (more or less) the Scrum process for two years. The Scrum rhythm of biweekly planning, demo, and retrospective with daily stand-ups served us well most of the time. However, we have since shifted to a process that looks more like Kanban. 

The Transition

We had the most friction with the Scrum process after initial releases when our focus turned more toward support and training of our customers. The two-week planning cycle does not accommodate this kind of reactive, responsive work. The dissonance between our stated process and the reality of the work day felt like a process breakdown even though what we were doing was clearly the most important thing for out team. It tended to make everyone a little cranky. Since agile is all about inspect and adapt and choosing a path that gets results, it was time for some adapting.

Our Flavor of Kanban

Unlike Scrum, which has identified creators and a set of doctrines that define orthodoxy, Kanban is more loosely defined. Our idea of Kanban starts with Scrum and and makes a few modifications.

We no longer plan a sprint. We simply pull stories from the backlog as we need more work to do. The VersionOne storyboard gives us a visual of how many items are in each status, and we only pull in a new story if the inventory level are low across the board.

Instead of planning for an entire day before a sprint, we now plan stories whenever the backlog of planned stories is low (less than a few days worth). We still demo the product and hold retrospectives every two weeks.

Since we no longer have sprint boundaries, we needed to make some changes to the way we integrate stories so that we always have a potentially shippable product. We now do all story or defect development on an activity branch in the repository and only merge back to the trunk after it has been thoroughly tested. This creates a bit of new overhead, but we’ve found it worth the effort.

Result

Now we are able to be responsive to new items that come in. The development team feels less jerked around when support issues come in and priorities change. We’d all like to get back to pure product development, but better to face reality as it is than to pretend it is something it is not.

Peopleware: An Aging Classic

Posted on by
1

Peopleware: Productive Projects and TeamsSome months ago I was telling a friend at work how everyone in the software industry should read Peopleware by Tom DeMarco and Timothy Lister

I have always said that Peopleware should be required reading for anyone who manages software developers. I’ve also said that if you want to know my philosophy as a manager, just read Peopleware.

However, the first edition was written in 1987 and the second edition, which I had read, was written in 1999. I decided to read it again. I was curious to see how it holds up more than ten years later.

On second read, it is clear that Peopleware was written prior to the agile wave in software development. However, Peopleware was such a prescient work that in 2011 I still found it to be insightful and compelling. Much of what they call for has become more commonplace since 1999.

As DeMarko and Lister railed against public address systems in the office, I felt like I had taken a trip back in time. However, the principle that management too often optimizes the wrong factors in the workplace is as relevant as ever. I’ve seen too many situations where more care was put into color schemes and aesthetics than the mechanics of how the software team would work together (acoustics, workstation configuration, etc.).

The insights and anecdotes on management of software people made the second reading worth the investment. The chapters on building a high performing, jelled team were especially valuable.

Bottom line… I still believe that everyone in software should read Peopleware and that managers must read it.

Working with Recruiters

Posted on by
Reply

Where I work, we needed to add some capacity to our product development team. It was a short term need that could have turned into a long-term need if things go well. We were looking for a contract developer for a three to six month contract. Sounds easy enough, but there were some complicating factors:

  1. In order to help with the short term need, we had to get the person in pretty quickly.
  2. We’re didn’t have a lot of time to devote to recruit someone.
  3. Our current team is very effective.

The first two items are typical of any team needing to increase capacity. Item number three is where it gets interesting.

When I say that the current team is effective, I mean that we get a lot done, we enjoy the work, and we enjoy working together. We believe that the product and the codebase is getting better with each sprint.

I attribute this to core values we have as software developers:

agile: We believe in deferring decisions to the last responsible moment to keep our options open and to be able to adapt.

object oriented/domain driven: We start with the domain concepts and the object model and not the database. We’ve leveraged NHibernate on the server and object serialization on the device to eliminate buggy hand-coded SQL.

software craftsmanship: We view software as a craft to be mastered, not by learning a new technology like WCF or WPF, but by developing sound judgment and applying the basics like those expressed in the SOLID principles.

XP/Scrum: We embrace the engineering practices expressed in eXtreme Programming: collective code ownership, continuous integration, pair programming, and automated testing.

The developer we add to the team must already value these things or must adopt these values to work effectively. A developer arguing to implement a stored procedure on the next feature because it would be more efficient (whether right or wrong) would be counterproductive. Someone opposed to pairing on tasks would reduce the team’s energy and be a distraction.

The first problem is that it is difficult to communicate the values that make our team effective to a recruiter that doesn’t have the context.

Recruiters tend to fall back on what they know… more experience and greater sense of leadership is better. This leads to a paradoxical problem: the more experience a developer has and the more leadership he has shown, the more important it is that he (or she) be a fit for the team. Less experienced developers are 1) more moldable and 2) less responsible for their experience.

The Advantage of Inexperience

Less experienced developers tend to be more open to learning new skills and adopting new values. The good ones recognize that they have a lot to learn—both in techniques and what fundamental values lead to better software.

Less experienced developers also tend to have less control over the the technology and methods they use on the job. They often don’t know what to look for in accepting their first job or two and don’t have the influence to change the direction once they get there. So, I hold less experienced developers less responsible for their lack of experience with object oriented, domain driven technologies and insistence on agile methods.

The Burden of Experience

Developers with many years of experience tend to be the leaders within their teams and organizations. They are the ones who drive the technical decisions and shape the values of their organizations. Because of this, we have a higher expectation that these developers are experienced in the techniques we use and hold the values that we hold. If they don’t, it is mostly likely that their convictions are more settled and they are much less likely to change.

Communicating to Recruiters

Evidently, I was ineffective in communicating this idea to the recruiters who were helping us. Recruiters continued to send people to us touting ten years of SQL Server stored procedure experience or any combination of Microsoft technology TLAs. I don’t think they understood what I meant when I would said that a particular person had too much experience (of the wrong kind).

So, I brainstormed with the team and tried to spell it out with a diagram that looked like this:

ExperienceVsFit

I thought maybe the picture would do what the thousand words hadn’t. No such luck… I had to explain the chart to guys on the team; so, there was no way this would help the recruiters. Undaunted, I made one more attempt, this time with a simpler drawing:

ExperienceVsFit2

I thought maybe this “magic quadrant” style graphic would work better, but consensus was that it still didn’t make it simple enough.

So, I gave up on the conceptual approach, and boiled it down to some questions, based on the years of programming experience the person has.

For developers with 1 to 4 years of experience, only one question:

Would you like to work on a agile team?

I went on to explain that we think a less experienced developer will adapt to our style of working if he/she is interested in learning the way we do things. We also think it will be very valuable and marketable experience.

For developers with 5+ years of experience:

What are the SOLID principles and why are they important?

What are three principles of Domain-Driven Design?

What does CQRS stand for?

What is your favorite ORM and why?

What CI tools have you used?

The candidate should be able to answer at least 3 of the 5 questions without hesitation. Someone without the experience we are looking for will probably not recognize the terms and won’t be able to answer them.

The idea was that an experienced developer who does not embrace the agile/DDD approach would not be familiar enough these terms that are peculiar to that world to answer the questions. The answers themselves are not that important (anyone does not use them won’t be able to interpret those answers, anyway), but familiarity with the terms indicates that we should talk to the person.

Because of some short-term issues, we put off the hire. I am hopeful to give this approach a try soon, though.

Developing for Android on 64 bit Windows 7

Posted on by
Reply

The instructions on the Google site for setting up for Android development within Eclipse on Windows is pretty good. However, there are a few things to watch out for (as of today, July 23, 2010):

  • Stay away from Eclipse 3.6. The Android Plug-in does not fully support it.
  • Choose the 64 bit Windows version of Eclipse 3.5 (SR2) classic.
  • Choose the 64 bit version of the JDK 1.6 update 20. There are reported problems with update 21 and Eclipse.

Raising The Bar: Manifesto for Software Craftsmanship

Posted on by
Reply

I’ve long been a fan of agile software development as crystallized in the Agile Manifesto. However, I’ve also felt like the core tenants laid out there are too vague to help software organizations actually be successful. I’ve recently learned of (and signed) the Manifesto for Software Craftsmanship. It is still short on details of how to do it (as I guess any document of this nature must be), but I think it is a nice raising of the bar of the original manifesto:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software

Not only responding to change, but also steadily adding value

Not only individuals and interactions, but also a community of professionals

Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

© 2009, the undersigned. this statement may be freely copied in any form, but only in its entirety through this notice.

Bob Martin does a great job expanding on it in this Software Engineering Radio interview.