Thoughts on Business Driven Development

From a developer perspective, there are many approaches for a feature development, it can be Test Driven Development (TDD), Behavior Driven Development (BDD) etc. Developing new features should always be in the context of the product development. In that perspective, the notion of TDD might be misguiding since developers are perceived as “driven” by tests. Any feature development should be driven by the business.

But why the business should interest developers?

“The Business represents the customer. They want to make sure that we are bringing the right features to market at the right time” — The Role of the Product Owner, Lee Eason

Developers might not be fully aware of that, but developers are making business decisions all the time. When they write code, each line of code is a product decision which translate to a business decision. The quality of the code, how much it scale, how much time they invest in testing and how fast they can go live are all critical to any future business decision. Why? because developers know best what they’ve developed, and how much time it will take to refactor it. The code is more accurate than any spec or documentation. A few years ago, I made a small refactoring, extracting dozens of methods from different persistent services to a single component and naming it “recommendation service”. A few years later, this service eventually became a core business component of information management.

Other examples for the need of being driven by the business are “Hackathons”. Those one-time events may be the result of a disconnection between the teams. Hackathons should not be driven by the developers ambitions to “hack” something (well not only..), they should be a business requirement to the developers to build features that are valuable to the business and easy to develop, the process of so-called “hacked” features should be a standard in any product development process.

Developers must have daily communication with the business team. Those developers who understand the value of their technical decisions to the business will eventually become the future of the company. Eventually, having success is all about the people and how much they are excited from their work. Every company that wants to have developers that are attached to the product, but also flexible enough if the business requires so, needs employees that understand the big picture, and can adapt to changes while still being able to get attached to next product.

Shifting mindset toward business-driven-development can make a big positive change to your team productivity and motivation. The “Feature Factory Syndrome” phenomena happen when zombie-coders are coding feature after feature without being able to see the big picture. This may result to demoralization and frustration. In a business driven development, the developers are fully aware of the business goals and how they are being converted to features that create a successful product.

In the next posts, I will explain the definition of product owners, flat organizations, bottom-up decision ownership and exposing business challenges for making that change.

Like what you read? Give Itamar Berger a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.