Believe Driven Development

Years ago I was young programmer starting his professional programming career. I had my eyes widely opened. And I was lucky. Very first project I was assigned to was driven by boss-of-my-boss who was incredible source of inspiration.

When we get raw specification I started rolling up my sleeves and starting my IDE. I wanted to program. Now. But I was disappointed. We spend incredible amount of time on meetings with customer (it was internal one) where we tried to get not only what  customer wants, but also what is its motivation for it. And not only that - we learned step-by-step business domain of customer - vocabulary, rules, conventions, best practices, etc.

We spent so much time with it that I was more and more skeptical about finishing project before deadline. But deeper and deeper we were in discussions I more and more realized how wrong product I would build without this information.

Then there was this moment from when we started to get feeling we are discussing same topics again and again but there is no resolution to discussed problems. That was correct moment to start implementation. We were aware of many problems we may have. That was enough, it was not necessary to have answer for them. It appeared later that some of them had simple solution, some had no good solution and some were just virtual problems that disappeared. But we were aware of them.

As Dwight D. Eisenhower puts it:

Plans are nothing; planning is everything.

I don’t have to say that project was successful and that software is still in production usage (12 years now). Since then I used this approach many times and it always led to less stress development and better product when compared to other teams that uses Believe Driven Development (BDD), as I named it.

So what is BDD:

• You believe your assumptions are correct
• You believe you understand customer needs
• You believe that customer understands his needs
• You believe that you understand business domain
• You believe that you don’t need to analyse complex environments (business rules, future requests, machines, software) in advance
• You believe customer is providing correct information
• Customer believe you can deliver what he dreamed of

Opposite approach of  BDD would be Assurance Driven Development (ADD):

• You assure your assumptions are correct
• You assure that customer knows what it needs
• You assure you learn enough from business domain
• You assure you understand complexity of environment
• You assure information provided by customer is correct

Be suspicious. About customer, conventions, rules, your assumptions, … everything. Put all of this to the test. Asked for same information from many points of view. Make sure you build correct model of reality in your brain. Then start, but assure you validate your model again and again and again as time goes and new information appears. As Elon Musk does.