headwind (u/headwind)

headwind commented on Ask HN: Business logic is slowing us down · Posted by u/headwind

atlantic · 2 years ago

Exactly. What the OP is saying is: my users are getting in the way of my programming. This is nonsensical. Giving business users good tools to do their job is the whole point of software development. Implementing those tools is our job as developers; but the end goal of the software should not be changed to make development easier.

headwind · 2 years ago

To be clear, every dev must understand and delight their users (including internal stakeholders).

But we also need a better way to empower and serve business teams by letting them control and manage the business logic. Keep in mind, we slow down the business teams if we cannot implement fast enough.

Carrying the mindset that devs must own everything can be harmful and counterproductive. In this case, there seems to be a mutual benefit to both sides. If you don't believe so, let me know.

headwind commented on Ask HN: Business logic is slowing us down · Posted by u/headwind

taylodl · 2 years ago

You're conflating different things here. What triggers user notification is business logic. How something gets named/logged in the database is not.

If your stakeholders don't understand the value of maintaining work and don't have budget set aside for that activity then that fail is on you (maybe not you personally, but your technology organization).

Empowering business teams to control and manage actual business logic, is a great idea but it doesn't come without its caveats. There's no Silver Bullet, that logic has to be stored and maintained somewhere. That logic has to have an interface to it that's callable by your system. Those interfaces need to be well-defined and everybody needs to understand exactly how the business logic affects the runtime operations. That business logic also requires version control management and release management. You also need a test environment. Guarantee some dumb ass will "fat finger" something and push it out and your system will come crashing down. If you can't roll back that change or restore the previous logic - your life is going to be hell. And do you know who's going to get the blame? You. It's your fault for letting them do something stupid.

These problems are enough to scare most people away from this insanity, but in case you're still persisten there's one more hurdle facing you: performance. You're taking logic that is currently hard-coded in with the rest of your program execution environment, and you're outsourcing it to another execution environment that has an API of some kind. Imagine what exporting the condition of an IF statement to an API is going to do for your performance! It's insanity.

I've seen many shops go down this path and I have yet to witness success. What you're advocating for is worse than the problems you have no. Sorry mate. Oh, and if you talk to IBM, they'll swear up and down that they have a tool that can do this. It's crap. I've been down that path. I've been down that path with Oracle, too. And various open source projects.

If anyone reading this comment as a different experience, a successful experience, then I'm all ears - I would love to hear it!

headwind · 2 years ago

Have any of them tried feature flags or other approaches? Curious what some shops have tried.

headwind commented on Ask HN: Business logic is slowing us down · Posted by u/headwind

illuminant · 2 years ago

It sounds like a lack of coherent design strategy. That is the sacrifice feature driven projects face. A problem which usually wears in after about three years. After market entry yet right when regular additions pile up and begin to cross paths.

The solution is a maverick mind who can drive coherent code strategy.

Business logic isn't your problem, an unfaithfulness to the idea that the application is first a business logic machine may be. User interface should be a layer, instantiating and manipulating a logic API.

Configuration over code is one ideal philosophy. Design such that configuration may established what types of things, or where they might route.

This would only work if all parts of the application agree on a configuration convention.

headwind · 2 years ago

Where have you seen configurations housed? Are there any great solutions for where to store configs so that business teams also have visibility?

headwind commented on Ask HN: Business logic is slowing us down · Posted by u/headwind

proc0 · 2 years ago

The core of the problem is that engineers do not own their code. It would be like a chef not owning their food. Engineers are split into teams that the business side of the company decides arbitrarily... and because non-technical leaders are not as familiar or knowledgeable about computer science, they create incorrect abstractions that constrain the solutioning for no reason.

Imagine an app where you have feature A, B, C, where A and B are basically the same feature with a few differences, and feature C is completely different. The business side of the company might decide to create three teams, one for feature A, one for features B + C, and another for features A + C. The engineers in each of these teams are immediately setup to create complexity in the long run because the correct abstraction would be A+B and then C.

headwind · 2 years ago

Right, why wouldn't it be best to let the business logic live with the business teams?

I agree with team ownership. Unfortunately, teams and their ownership domains are organized in odd ways due to business needs.

However, that suggests to me that there's more reason to house the "ground truth" with the team that owns the ground truth.

If 3 teams each own different features, they'll each write their own business logic.