Data Driven - Good or Bad?

Have you ever wondered what Data Driven means? Are you certain about its meaning? Are you certain that it means only good or only bad?

Data Driven can mean either good or bad, depending on the context. I will explain both sides now.

Data Driven - the Bad

I'm coming from DDD (Domain Driven Design) world. My head is heavy with objects and the truly object-oriented coding style.

For me, having my background, "Data Driven" by default means Bad. That's because I imagine code written as data. Every object is a mere data container. No behavior inside objects. Any method in the large codebase can do anything to the objects. Everything knows little bit of the business. And nothing really owns it.

Such codebases are scary. They scare professionals. Not because they don't know how to deal with it, but because they see the problems the code will cause sooner than later.

Interestingly, these codebases don't scare amateurs, low-skilled engineers, or contractors who are with you temporarily to quickly get the job done and drop the software on your shoulders when your budget is up. These people are not scared either because they don't know what they are dealing with, or because they know it won't ever be their problem.

A right way to write software is to learn and engrave business knowledge into objects. This is achieved by following object oriented principles (importantly, in this context, encapsulation and abstraction). Domain Driven Design can help on more advanced level, by connecting the dots between business and code.

Regardless of how far you want to take it, truly object-oriented code has knowledge in it. You can use existing constructs without examining them every single time when you want to use them. You trust objects and use them as they are the expression of the knowledge in the business. By using those objects, you construct and execute business rules and constraints.

Code written in such a manner not only saves your time (because you trust many times without further examinations), but also is a pleasure to work with, for professionals. That's because it won't cause problems.

This is the kind of software that every professional developer tries to achieve with every new project attempt. Unfortunately, due to lack of information around these rare skills, and lack of skills obviously, they introduce same kinds of problems every single time. (By the way, this symptom of attempting to write a better software every single time is real. I know it as a developer, and I have heard from many other developers too)

Back to the main point - truly object oriented code cannot be said to have "data driven" style. It will be "domain driven".

That must explain why "data driven" is a bad word in this context.

Data Driven - the Good

I was recently contacted by a recruiter from one well known company. During our conversation, when he was pitching how well the software development process is organized there, he threw this phrase to me: "we love data, our engineers love data driven approaches, and our software is built in a completely data driven manner".

I was shocked for a moment and wanted to interrupt him and say that our deal does not sound like a good match, because I'm an object bigot. I'm anything but data-driven. I'm domain driven...

But then I gave my reaction a second chance.

The recruiter is not a software developer. Probably he used the term "data driven" to denote that the decisions in their company are made based on data. This can be experiments, A/B testing, customer feedback, and so on. He went a bit too far by saying that even the software is written using this style. He definitely could not know how the code is written... Well, okay, I suspect that the code could be written in a [bad] "data driven" way, but that would be caused again by the same reasons as stated above. Clearly, a recruiter would not announce something that is not so good in his elevator pitch.

Anyway, data driven decisions are great. I'm all for learning and studying the environment and use cases before jumping to code and designs. I'm also for designing before jumping to code, because design also produces another kind of data - clear plan and vision of the final software.

All in all, as somebody once said - "without data you are just a person with opinion".

Do run your business in a data driven fashion.

Back to the point, data driven is a positive term in this context.

Final Word from Developer to Developer

As a developer, I ask you, please don't write code in data driven fashion, even if your company loves "data driven everything". They don't mean to tell you to write non-maintainable, complex code.

Learn and follow better coding and programming techniques, and you will be able to build software to the standards that you dream of.

Are you curious how I write domain-driven code? Check out my other articles or ask me about the technical training for your team.

About Author and Content