Software development is saturated with frameworks, methodologies, and processes, most of which come with the promise of better development. Just ask any developer, and they will likely be more than happy to share their favorites or suggest which method you should use.

Are you looking to implement a large project successfully? They could suggest a method. Are you trying to avoid discrepancy between design documents and what is actually implemented? They know a framework that’s perfect for that. And if you wanted to ensure your project has minimal regression and is maintainable over time, then they certainly know what process you should follow.

But what happens when the complexity of your projects grow and faithfulness to just one method doesn’t provide the benefits and value your project (and the user) deserve? As we learned from the hybrid cloud, very often the best solution to a complex problem is a combination of several. 

You may also like:  Hybrid Test-Driven Development

Today, I am going to share with you how to tackle difficult and complex development in the agile space using not one method, but a hybrid combination of three specific ones. 

The 3 Methodologies

The promise of better development through a hybrid solution of multiple methods works, but you can’t utilize just any three. They need to be complimentary, they need to pick up where another falls short, and they all need to provide their unique value that assures predictable and productive outcomes. In short, the perfect combination is TDD, DDD, and BDD. 

Test Driven Development, or TDD, is a process of developing software where a test is written prior to writing code. Once that is done, developers will work towards writing just enough code to pass the test, and then begin refactoring. 

Domain Driven Design, or DDD, is an approach to development that connects the implementation to an evolving model, placing the focus of the project on the core domain (sphere of knowledge), the logic behind it, and forces collaboration between technical and nontechnical parties to improve the model. 

Behavior Driven Development, or BDD, is a refinement of TDD and DDD that aims to streamline development through narrowing communication gaps, creating a better understanding of the customer, and allowing for continuous communication. Simply put, BDD is a way of combining business requirements with code and allows you to understand the behaviour of the system from a business/end-user perspective.

While those above are all standalone and beneficial frameworks in their own right, as I mentioned earlier, the demand for more complex development is and has proven itself too much for any single one, but not all three. 

A Hybrid Practice

Combining methodologies in order to reach the desired outcome seems like a great idea, especially in theory. However, it isn’t enough to just combine these methods and hope for the best. Aside from having organizational buy-in and a shared understanding of these concepts singularly amongst your teams and its members, the most crucial step is to understand when and where to utilize these frameworks to ensure maximum output. 

So where do we begin?

Well, knowing that the first step to solving any problem is to truly understand the problem you are trying to solve, the only logical place to begin from is the outside in. 

Thinking Outside In (BDD)

Before a single line of code is written (or even thought of, for that matter), you need to begin by understanding the problem you are trying to solve, how the problem was created in the first place, and perhaps most importantly, what value you project the solution to have. In this discovery phase, it is best to make use of open-ended questions to determine what specific pain point you are trying to alleviate, who and how will they benefit from it, and what impact will it have on the organization. 

At this point and if done correctly, you should have a good understanding of why this development is beneficial and a clear vision of what to build. So far it has been BDD taking us to this point, now it is time for DDD to take over.

Thinking Big Picture (DDD)

What is the best way to tackle a large development project? You break it down into smaller, more manageable segments, or in the case of DDD - domains. When you split the project into smaller domains, you can have segregated teams handle the functionality of that domain end-to-end. And to best understand those domains, you enlist the help of domain experts; someone that understands the problem and that realm of knowledge more than anyone else. 

Typically, the domain expert is not the one who is responsible for developing the solution, rather, DDD collectively is used to help bridge the knowledge gap that usually exists between these experts and the solution that is trying to be realized. Through models, context, and ubiquitous language, all parties involved should have a clear understanding of what the particular problems are and how the ensuing build will be structured. 

Thinking Inside Out (TDD)

I know what you are thinking: “At what point do we start writing code?” Well, the answer is now, but before you do, you need to write a test.

As previously discussed, TDD is a practice where you write the initially failing test first that defines a function, and then you go back and try and write the minimum amount of code for the test to pass; followed by refactoring to ensure acceptable standards. 

But why did we wait so long to write code? We are still talking about development, aren’t we? Yes, of course, we are still talking about development, but we are talking about quality development, and that means bug-free development. In broad terms, there are two types of bugs:

1. The ones that cause your system to crash 
2. The ones that show the wrong results

By taking the above-mentioned hybrid approach to development, you will find that TDD helps you mitigate and avoid the first type of bugs, with BDD and DDD helping you avoid the latter -- which also happen to be the most expensive to fix. 

Moving Forward

As the complexity of your projects grow, the only way to maintain the viability of your build and ensure success is to have your development practices grow with it. While the individual practices of TDD, DDD, and BDD are all valuable in their own right, it is the point at which they intersect that will provide the real value moving into the future. 

Now, if you are faced with a large project that demands zero discrepancies between design document and implementation, requires minimal regression, and is maintainable over time, you can suggest an approach to that -- more specifically, a hybrid approach that utilizes these three methods. 

Further reading

What is BDD and What Does It Mean for Testers?

TDD: Where Did I Get It Wrong?

An Introduction to Domain Driven Design and Its Benefits