4 Key Ingredients of (Almost) Every Software
Updated: May 15
Have you ever pondered why software development feels repetitive? Have you ever noticed that it's repetitive?
Have you ever tried to figure out what are the steps you are repeating over and over day by day? Has it ever led you to create frameworks to make your job feel less boring?
I think I'm not far from the truth if I assume that most of the developers answer yes to the above questions. This is what makes frameworks like Rx, Angular, React, .Net, Spring etc. come to life. They bring something that offloads a few tasks from the developers’ shoulder, so they can concentrate on the real business problems. It's the same way how new programming languages and paradigms emerge, evolve and then are replaced by something that supersedes them.
About 15 years ago I found a pattern that gave me this boring feeling. And as I investigated the root causes, I figured out, that every software I met had the same abstract design. I developed my own "framework" and have been using it since successfully to offload the burden of getting tired all the time. Regardless of the niche of the customers it always works.
What is every software built around? What is the only component, that leaves the software useless if you remove it? Data. And it's not surprising at all. Having buzzwords around like "Data Driven Development/Design" or DDD for short have been seen for a few years now.
Let's talk about the four ingredients that every DDD process have to have an answer to:
1. Data Structure
What kind of data do you intend to store? How do you categorize them? Can you split them into smaller chunks? Do you need to split them?
This is about everything on the topic of normalization. But remember over normalizing is as harmful as having no normalization in place. And it's tricky to find the balance between the two.
2. Data Collection
Where does your data come from? Do you have single or multiple sources? If the latter, can you join the data sources so that the aggregated result has value? Are your data collected once, regularly or irregularly? Do you have a mixed setup? Are you prepared to synchronize your data sources so your application can give meaningful responses any time a user arrives?
Are you prepared to handle errors in your data? Will poisonous data break your application? Will users complain about errors?
3. Data Presentation
How do you intend to visualize your data? Can you make sense of your data or it confuses you when you look at it? Does your data structure enable you to make decisions based on the collected data?
4. Data Flow
Will your data mutate over time? Is it intended or misbehaviour of your system? Is it automated or user-driven? Do you need extra processing between data collection and presentation? Can you communicate the mutation of data through the presentation layer?
Lots of questions that have loads of best practices all over the internet. I agree to some of them, I disagree with others, but at the end of the day, it only matters if it works for you. But if these are so obvious, why did I start to write about it? Good question. Because what I've outlined above is just the tip of the iceberg. What I have found is deeper beneath the surface, harder to capture but makes development much easier once applied.
But that's the topic of my next post. Until then one more question for today:
Are you sure you are looking at the right data for your application?
Have a good day!