While at PHPBenelux 2014, Bert Heymans of our team went to see the “Moving Away from Legacy code with BDD” talk by Konstantin Kudryashov . You can find it here on Slideshare. For Bert, this talk was inspiring and from a project management point of view, this talk made a whole lot of sense to him.
Don’t Google BDD, it will get confusing really fast. In the context of this article BDD means Behaviour Driven Development, it is part of Domain Driven Design (DDD), and it’s based on the software engineering methodology called Test-Driven Development (TDD).
Now that that’s cleared out, these are the key take-aways from the talk that stuck with Bert as a project manager:
- The cost of change in a legacy project (with bad code) is exponential.
- The goal of BDD is to help communicate rules with software engineers and business analysts by sharing tools.
- BDD helps focus on delivering value. In this way every good project has a clear business case and everything that helps focus has our vote.
At some point you may be confronted with a system that has an unhealthy and old code base, it will be hard to change and expensive if you do. It probably won’t be too much fun to make change happen to such a system either.
But does it have to be that way?
Fixing bad legacy code can be done by re-building the same solution from scratch or by refactoring the code entirely. If the old system works enough, from the perspective of the users you can change whatever you want under the hood, it wouldn’t matter to them. The user experience is the application.
Without adding features or improving existing ones, there’s no perception of added value. In other words, it might be very hard to get support for “just cleaning up code”.
It would make more sense to work with descriptions of the expected behaviour of the system (ultimately in the form of written BDD tests) and work on modernising key parts of the codebase as you go along. That means ensuring existing functionality, adding features and cleaning up code at the same time.
Take a BDD tool like Behat for PHP for example, it is great for such purposes because it will help collaboration and documentation with the focus on value (described by features and usage scenarios). The tests should be written in such a way that developers, business analysts, domain experts and clients understand them, it’s what BDD calls “getting the words right”.
Bert would consider using a BDD approach in a project for the following reasons:
- If the businessrules you’re dealing with are very complex.
- For helping a team speak the same language in order to create a single definition of ‘done’ that everyone understands.
- If you need to build on existing business knowledge.
You’ll find quite a few discussions and rants online about who should write BDD tests. Some people make a silly argument that users or clients should write test code for the methodology to work but that’s completely besides the point. Someone who can write code should write them as a result of collaboration between development team, analysists and other stakeholders such as the client and the users.
One of the core values of agile software development is “individuals and interactions over processes and tools”. As always, tools are no substitute for proper communication but using the right tools for a job can make a real difference.