Hello and welcome to this post which is a little bit more of a water cooler according to what I usually post here.

Today I would like to react and discuss with you about an interesting post I found on X made by Andrew Sherman.

• The question
• Feedback on the answers
• What I thought during my early days as an engineer
• What I think today
• A solution to a business problem
• Predzo: my personal playground
• Conclusion

 The question

Scrolling on X, I found Andrew asking the following question to his followers.

When you start working on a backend, do you prefer business logic first or database modeling first?

The audience is tech, and after I scrolled over a dozen of answers, I made a small summary over the 58 comments I passed through.

• 16 were for the "Business logic" first approach
• 42 were for the "Database modeling" first approach

Feedback on the answers

I can pull two category of answers:

• The people that strongly believe one way or another
• The more nuanced people, that are unsure of which approach is the best

The last category is a minority. I am not surprised that overall people are quite sure of themselves about this question, because they might already have some experiences implementing it in their work place or on a personal project.

What I thought during my early days as an engineer

I work on the tech field since 2013 and I had many tech opportunities including working for several companies.

If you would have asked me this question back in the time, I would have answered to go "Database first" as it is the most obvious choice for me.

When you think about what comes first when building a feature or a project from scratch, the data storage layer is our first thought. Choosing a good storage medium can have a big impact on how the feature will be conceived.

While this is a natural way of solving a problem, by laying down a database schema and identifying the culprit and opportunities, I think this is reducing our range of action.

What I think today

Before working on my current company, I always had a tech-first approach, and most of the solution I built was decided by engineers. While it was working pretty well, I could defintely see the limits of this approach.

Because of this, we could totally miss the point and put a lot of efforts on something that the end user would probably not find as useful as we would as tech engineers.

The first time I changed the way I solved problem was a little bit after I was hired in for my current position. I discovered the concept of a "product team".

This team was dedicated to understand the user need, and translate it in stories/features. We, as a tech team, would then work closely with the product team to deliver values to the end user.

Suddenly, everything made sense for me. I finally could put words on the feeling I had back then when I felt something was wrong with the way we would solve problems: we missed to put the user at the center of the solution.

A solution to a business problem

For the first time since I started my career, I have the feeling to really contribute and make my company progress to deliver a higher value to our customer.

Isn't it what we strive for a engineers? Finding solutions to real world problems encountered by real humans like us?

When you put the business as a first-class citizen in your way of solving problems, the path gets so much clearer. You instinctively evacuate any superfluous thought or overkill solutions to just focus on how to solve the business problem.

This is why if I should give my point of view now, I would go for the business approach first.

 Predzo: my personal playground

2 years ago, as I was usually responsible for doing the groceries in my family, I always would struggle to gather the list of each of my family members.

Some would give me their list in the form of WhatsApp messages, cluttered between other unrelated messages, some would send me last minutes SMS for their articles they forgot to add on WhatsApp, some would copy/paste their Google keep list. In the end, it was a nightmare to not forget something and keep track of what was already in my cart.

To solve this problem, I first tried to lay down the need (my need so to speak). I needed an app that :

• could manage grocery lists
• could help keep track of what is checked/in my cart
• could allow to share grocery lists and ease the collaboration
• could be usuable on any devices (responsive)

I started to wonder in Google and made a list of potential apps I could use. Unfortunately, I could not find one that would fit all my criterias.

I decided to take advantage of this opportunity to bullet-proof the business approach.

Instead of starting with a database schema, I started to sketch the UI. I made all the pages with Bootstrap 5 and static HTML to draw the user journey.

Only at this moment, I could start iterate until I was satisfied with the user story, that would hopefully check all the criterias I laid above.

It took me a month working on my spare time the night and on week-ends, and when I was statisfied, I started to split all the user journey into tasks on Trello.

Each tasks would consists of:

• The data persistance layer
• The UI
• The business rules

2 years later, Predzo is on production, and I can confidently say starting with the business empowered me and helped me focus on the essential and move at a good pace, instead of polluting me with technical, overengineered solutions.

 Conclusion

My general thought about working as a web developer is that when you start switching your point of view about how you approach problems, it feels like you climb above the cloud: everything gets clearer.

Of course this clarity also came after I have experienced and made mistakes. I defintely think I would not understand why the business approach is the real long-term sucessful way of solving issues if I would not had experienced the other way first.

Bottom of the line, my mindset now is that we are engineers, puting technical solution at the service of users. The tech is just the tool.

This does not mean we should stop having tech conversation. It just means we can think about which tech solution to use once the user story is clear. Assuming for the user what the need will be is a sign the need is not clear and it is worth spending more time understanding it rather than pushing a solution nobody will find useful.

I hope this kind of post will make you re-think or challenge the way you approach your new problems in the future. I would also like to know what do you think about this subject. Let me know in the comments down below.

See you later and happy business problem solving!

Cover image by fauxels on Pexels.