For the last few months I’ve been on a steady mission to absorb as much about lean software development as I can. This morning I got up and decided to enjoy the morning air, slight breeze, my Zune and the start of the Poppendieck’s Lean Software Development: An Agile Toolkit book. After having read The Toyota Way recently, it was pretty clear to me that eliminating waste was a large component of lean ideals. In the first chapter of the Poppendieck’s book, how waste manifests itself in software development was cemented for me. I immediately started thinking about a recent experience of mine.

A little while ago I was asked to take a look at some modelling that another project was doing. The idea was that I would review it and contribute to a discussion with information on our project’s Domain Driven Design movement. I was provided with a forwarded copy of an email thread that spanned a conversation between a couple of architects and a senior level developer along with a small set of attached diagrams. Rather than initially working through the multi-page email thread, I decided to take a look at the diagrams. My whole though process boiled down to the fact that looking at four diagrams would provide me with much faster initial insight, and it did.

I immediately realized that the concept of modelling used on this other project was completely different than the model that we created organically as part of our DDD efforts. While the attachments did provide me with quick insight into the area of discussion that was being engaged, detailed inspection of them didn’t provide any information on the project. After reviewing all four ‘model’ diagrams, I still had no idea what the project was about. It’s at this point that I decided that I needed to read the email thread.

It was in the email thread that things got interesting for me. I’ll say in advance that I still have no idea what business area, let alone problem, the project is addressing, but that wasn’t the most interesting thing that I took from the reading. The email thread consisted of a series of five to seven emails spread out over approximately a week. The conversation was triggered by the initial question of “How do the different models you are presenting relate to each other?”. Through the remainder of the thread, the relationship between the models was no clearer to me.

My first thought was that the number of different models was creating communication friction. The different model diagrams that I had seen in the attachments seemed as though they were fragmented. While they were cohesive (in the programming sense), they were so loosely coupled that they didn’t tie together in any way. Combined, the diagrams didn’t create an understandable story for their consumer. This is what I initially thought the problem was.

After some thought though, I have decided it wasn’t that the project had four different models that weren’t tied together in any meaningful way. What I think happened is that these diagrams were created to enhance communication where it wasn’t needed. In one of the diagrams it was outlined that the project would create a Semantic Model during business analysis, a Platform-independent Model during technical analysis and a Platform-specific Model during technical design. Overall the project was creating three models that, I’m guessing, were to represent the same business functionality. Three different views on the same thing. Does the business get any increased value by having these three representations created? Probably not. Instead they’re getting more effort required to do the initial creation of the models. More effort to maintain the models through the life of the software. More effort to communicate how the models relate.

All of that effort is wasteful since it doesn’t provide any additional value to the client. Lean software development is all about eliminating waste. I’d say drop multiple models in favour of one that accurately represents the business and is written in a way that allows all parties, clients, analysts and developers, to communicate in one language and context.