Multi-Driven Development

To avoid failure it is very important that everyone involved in the project understands what they are working on. The business that is working on a certain domain has lots of knowledge that needs to be understood by the developers who will do the technical implementation. This means that there is a need for ubiquitous language. It means that we build a language within a project that helps people to understand the concepts they are working on. Dan Haywood explains how to use it as follows:

"Build a common language between the domain experts and developers by using the concepts of the domain model as the primary means of communication. Use the terms in speech, in diagrams, in writing, and when presenting. If an idea cannot be expressed using this set of concepts, then go back and extend the model. Look for and remove ambiguities and inconsistencies."

But how to do this? What if the developer just doesn't understand what the domain expert is trying to say? Then you might want to add a business analyst (BA) to your team. A BA is a member of your team who can act as interpreter between the domain experts and the developers. They are a valuable resource with a big responsibility. If they fail to translate clients requirement, the development will fail. So choose your BA wisely.

Having a clear domain model with understandable language helps the development team to see the big picture of the software they are working on. It will also help them to point out dependencies, which will simplify the estimation process for example.

DDD will provide a good starting point when you are creating user stories. With the ubiquitous language, your user stories are easily understood by everyone on board. If only your developers can read the user stories you probably failed with DDD.

DDD should not stop when your technical concept is ready. As the software is developed and it starts to gains form, the domain model should be updated and more ubiquitous language needs to be added.

When you are doing DDD right, it will be easier to add another process to ensure higher quality while decreasing the amount of bugs in your code. When your developer team knows the domain model well and understands it clearly, it is easy for them to say what kind of functionalities will be added. With good DDD it is easy to start splitting the functionalities to smaller parts. When you have the smaller parts well understood you can write a test.

A test will contain some code that makes sure that your code is working. In TDD the process starts with the test. Not the production code. You define what should be the end results for each function and then start working on the production code to make the test pass.

What kind of tests should you include? With TDD I find it most natural to start with unit tests and functionality tests. After many years of working in the web industry I now tend to start from the backend and then move to the front end. With unit tests and functionality test you can already test a lot, even if you don't have the front end code in place. Of course, you need to decide which testing strategy matches your project and it's environment best.

Important part with TDD is to explain it's value to the customer. TDD might initially slow down your development a bit. But eventually, it will pay off and speed up the whole project once you start avoiding those nasty bugs.

Usually, when we talk about SW development, we mostly focus on the technical side of the work. But amazingly, soft skills are an essential part of the development process. Moreover, to create a good domain model, your whole team needs good soft skills.

Now what do I mean with: "driven by difference" and how does it relate to soft skills? The whole SW project team is compiled of different individuals each with their own unique strengths & expertise. This should be a driving force of the team. There are technical people, business people and people with strong management or organisational skills. Too often we hear developers complaining that the clients do not understand the technical details. Now, what if it might actually be meant to be that way? The clients are the domain experts in their line of business, providing the business details and this should simply be enough.

Expertise is not the only difference. There are more differences to be valued. Cultural differences, gender differences, background differences, generational differences and so on. Too often all these are seen as challenges and not as a force that can drive a team to reach the goals of a project. All these differences bring their own challenges but that is only one side of the coin. When you add a special ingredient called empathy, all these can bring lots of new and valuable insights to a project. I often experience this while collaborating with my multicultural team here at the Cambodian office of Web Essentials in Phnom Penh.

I hope you enjoyed these 3 concepts and that they can be helpful to get your team reaching your project goals.

Each concept brings its own value but combined they are awesome!

Looking for a strategic service partner for a web development project? Have a look at how we can support you with your next project.

Visit our products & services