Or you know, almost everything is…

Hello, humans! There is only one small and important thing that isn’t implementation details: business rules.

I like to say that I’m annoying… I really am! I worked a lot with nontechnical people and humans in general and also… I’m human (probably).

We, as humans, usually omit important details that we don’t think about. Sometimes they are really important and the current implementation could be as bad as it can be, but you can still forget all the hoops and loops you need for that important business rule to be met.

This is usually like people saying “Just go from A to E”.

Knowing that I’ll relentlessly ask over and over the same questions, changing the approach and making them think about it from different points of view until I’m satisfied (kinda like you do with ChatGPT to get a better answer).

This means asking “But what about the rest?” Getting an “Oh, yeah, there’s also C and sometimes D.” And then continue asking until you get the full picture, step as step, and more.

Business Rules

This is the only thing that is not a detail. It’s also at the core of whatever you’re doing and you should be spending as much time understanding it as you can.

The coding of business rules

Language, frameworks, and databases, or even if you’re gonna use coding at all… just details.

Then again, I’m also a programmer, and while sometimes you can just “throw people” at the problem, automating it is a more efficient way of doing things.

If you already have details like language, framework, or databases set, this, if anything should be as clear to understand as possible, and if you can test only one thing… let it be those rules.

While testing those rules, as long as you really try to “break” them, you can always find the equivalent case to the “bank example” where you can withdraw without having a balance. Any business rule will probably have something similar and testing usually give you a better insight on where to find those.

Relentlessly annoying

Then again, as the programmer, you probably don’t know all the rules.

I had already made the case, but I’ll repeat it here: you probably want some people who don’t know anything about the company, sector, or product in your team. Maybe even a couple that had never used something similar and even some “devil’s advocate” who might think it’s a "stupid idea”.

I’m not saying to have dissenters who will always oppose every decision, but people who will challenge assumptions, that will come from a new point of view. Those are people who will come with a beginner's mindset and/or make difficult questions that people from outside will also make.

Having that kind of people inside means that those questions were already answered and that your business rules, whatever they are, already account for that. Not only that, that kind of person can hold back a little of people too hyped to see obvious flaws. Basically akin to the writings advice of “killing your darlings”.

The implementation details

Whatever else and basically anything programmers love to talk and discuss… everything is just details.

When you hear that someone used Google Sheets as a database for the MVP of something… details. It worked until it couldn’t handle and then they changed.

Out there, you’ll still find someone using that approach and then think “What were they thinking?“ while cursing generations of people. Well, they were probably thinking: it works, it’s what I could do for now…

Details of the details

How they implemented is another talk entirely.

If they incarnated a pasta chef and served a big bowl of spaghetti, then go ahead and curse them!

After all, once you have the business rules clear, you still need everything else to support them. While a weak base can, has, and will bring down the best of the ideas, the best support will not make a bad idea suddenly good.

Everything coming together

This is actually a low bar to clear, once you have a good and solid idea with clear business rules. If you don’t challenge it as much as you can internally… you can end with something shiny but as fragile as glass, that someone will break.

After that, you just need something that will adequately support it and for most things, this doesn't mean much. It also means that you can use any language, any framework, and any database.

There might come a time or scale that “any” isn’t good enough, but as long as you remember that those are implementation “details”, then you know that they should be “replaceable” (which means clean code, good practices…).

Surprisingly, this is not obvious to all programmers!

Back to the example of the A to E, some programmers will jump to think of useless stuff like the details and forget to point out the obvious “But what’s between that?” Sometimes they just won’t see it, will code something that misses clear objectives, the “client” will not be happy and they will need to redo stuff.

This might also mean having to make more business rules fit inside support details meant for something smaller… and since nobody wants to redo everything again, they start with workarounds well… you probably know where this is going right?

Someone who accurately found that the rules are A, B, C.1, C.2, D.1, D.2, D.3, E and started in a Google Sheets already enclosing and separating concerns of what is a business rule and what is implementation details will go farther, faster and painlessly to something better than the one who got hyped on the “A to E” and with some luck added a “3” in the middle because it “made sense to them”.

Don’t be afraid to be annoying!

People might hate you. But that's better than wasting everyone's time on something that won’t bring that much value and/or having to redo or hack something to make it work afterward.

Recently I had to put my foot down. My contact point for what I’m working on wanted something for them but doing that would mean a lot of time used for something that you could just throw people at the problem initially, it was a problem but the next time it would be used would be only after several months.

So, instead of that, there were things that should be done before that couldn’t be done otherwise and would bring more value to the whole, although at the cost of not having what that one person wants.

This is a hard lesson because like others, the I in the past just started coding without having a clear picture of what were all the rules. I didn't know what was more important or what would bring more value.

There are, of course, times when you’re just handed down the what to do. But if you can, always asks for the why and then again and again until you have a clear view of whatever underlying business rules there are.

And after that, you know… just details…