[HN Gopher] Ask HN: Business logic is slowing us down
___________________________________________________________________
Ask HN: Business logic is slowing us down
As developers, we're caught between keeping up with our internal
stakeholders (operations, business, and data teams) and satisfying
external end users. We spend a nontrivial amount of time
maintaining our code to keep up with complex, ever-changing
business logic. Do we really need a code change for changing what
triggers which user notifications or for updating how something
gets named/logged in the database? Unfortunately, maintaining code
is also not considered valuable work. We're valued for pushing out
new features, and keeping existing features up to date with
changing business logic is considered short work. To be great
devs, we need to understand our users (including internal
stakeholders) and our industry domain. But we also need a better
way to empower business teams to control and manage the business
logic, while clearing the runway for devs to build the next
feature. How has your team handled this?
Author : headwind
Score : 5 points
Date : 2024-07-27 20:27 UTC (2 hours ago)
| taylodl wrote:
| 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 wrote:
| Have any of them tried feature flags or other approaches?
| Curious what some shops have tried.
| illuminant wrote:
| 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 wrote:
| Where have you seen configurations housed? Are there any great
| solutions for where to store configs so that business teams
| also have visibility?
| proc0 wrote:
| 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 wrote:
| 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.
| proc0 wrote:
| I would say there are different "ground truths". For
| engineers, this is computer science theory, and for business,
| it's what makes sense from a market perspective and what's
| best for the customers. This is why having engineers worry
| about customer needs is a huge mistake, at least in my
| opinion, because it takes away from engineers focusing on
| what they do best.
|
| The solution could be something like creating two distinct
| domains, and then bridging the gap. You would have the
| engineering domain, in which abstractions follow information
| theory, and then you would have the business domain, which
| follows whatever the business wants. Then you would need some
| kind of bridge, whether it's teams or roles in each team,
| that translate and mediate back and forth. This way the
| business can ask for XYZ feature, the bridge teams or roles
| would then consult with engineers how to break these up, and
| then engineers would implement it. Additionally, engineers
| would have complete ownership over their domain.
|
| I think the reason it doesn't work that way, is because the
| business side wants complete transparency over engineers,
| which constrains them for no reason. I also think these
| constrains are impacting the business value in the long run
| because software isn't being used to its full potential.
| revskill wrote:
| Business logic is real programming.
|
| What you described (non business-logic problems) is just "coding"
| level where you might integrate/compose libraries together at the
| boundaries of the system.
| atlantic wrote:
| 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 wrote:
| 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.
| korijn wrote:
| Take ownership.
___________________________________________________________________
(page generated 2024-07-27 23:14 UTC)