The Multi-Driven Development

In software development (SW), there are many approaches how to do it. There are different ways to start a SW project and to run them. All different trends and concepts give developers and designers tips how to achieve the goal and fulfill clients needs.

I suggest that combining some of the best trends and concepts will help your team to produce high-quality working software. You should not only praise one concept and count on it.

Here are some concepts that have helped me.

Domain Driven Design (DDD)

To avoid failures it is very important that everyone involved in the project understand 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 withing 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 cannot understand what the domain expert is trying to say? Then you might want to add a business analyst (BA) to your team. BA is a member of your team who can act as interpreters 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 be sure of who is your BA. 

Having a clear domain model with understandable language helps the development team to see the big picture of the software they are working on. This will also help them to point out dependencies, which will simplify  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 understandable 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 have its actual figure the domain model should be updated more ubiquitous language needs to be added.

Test Driven Development (TDD)

When you are doing DDD right it is easy to add another process that will ensure high quality and decrease number of the bugs in your code. When your developer team knows the domain model well and understand 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 your should include? With TDD I find it most natural to start with unit tests and functionality tests. I work in the web industry and tend to start from the backend and then move to the frontend. With unit tests and functionality test you can already test a lot even you don't have the front end code in place. Of course, you need to decide best testing strategy matching your project needs and it's environment.

Important part with TDD is to explain it's value to the customer. TDD might slow down your development at some point. But eventually, it will speed up the whole project when you can avoid some nasty bugs.

Driven by Difference (DBD)

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

But what do I mean by the phrase: "driven by difference" and how it relates to soft skills? The whole SW project team is build with different persons with different expertise. This should be a driving force of the team. There are technical people, business people and people with organization skills. Too often we hear developers complaining that the clients do not understand technical details. The truth is that it might be that actually, it should be that way. They are bringing the business details and they are the domain experts and this is enough.

The expertise is not the only difference. There are more differences to be valued. Cultural differences, genre differences, background differences, generational differences and so on. Too often all these are seen as challenges and not as a force that can drive the team to the goal of the 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 the project. I have experienced this when I have worked in a multicultural team at my current workplace Web Essentials here in Phnom Penh.

DDD + TDD + DBD = Multi-Driven development

So I have introduced few concepts that can be helpful to get your team to reach the project goal. Each concept brings their own value but together they are awesome!