Ask HN: Business logic is slowing us down

A lot of this comes down to poor product management.

A shitty PM sees problems like "when a guest at a hotel room completed {specific action X}, they want to receive a notification saying {specific message Y}".

A half decent PM will stop, step back, and ask "is there a meta-pattern here that I'm just not seeing yet", and realise the actual requirement is something like.

"When a guest at a hotel is the subject of any meaningful business event related to their booking, the management of the hotel want to be able to send them some kind of configurable, context-bound notification containing information about that event (ideally with some simple conditional logic to skip scenarios where the notification isn't relevant).

As an engineer, you're going to look at those two requirements fundamentally differently, and sure, the second one is maybe 3x harder to implement initially... But once you're 20x different "bespoke notification events" deep, you're gonna bloody wish you built the second option from day one.

Src: am Snr PM who sees teams get screwed by this type of bad PM thinking all the time.

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!

Learn to manage the managers. In some companies, this simply isn't possible. Org charts are like software architecture too. These have to be engineered by the person at the top, and you need things like servant leadership. Bad managers should be removed.

Code complexity goes up with more features. But also product complexity. I was actually looking for a product that did X for my residential community. My previous job did WXYZABC. Our community went with the crappy competitor that only did X and did it at 200x the price. There were lots of features because we learned to build fast and the price was low because the costs were low. We could have charged the 200x and conquered 80% of the easy market, but we went for bigger markets that we could barely reach.

I think the ideal is having teams that do only one thing. People love to talk about how efficient WhatsApp is, creating billions of dollars of value with like 40 people or whatever it is. But nobody wants to build a WhatsApp. They all want superapps, even though these are less efficient in every way.

Internal stakeholders are still users, and if they have a constant need to change business logic flexibly and without involving the devs every time, maybe it's time to build them a configurable workflow?

It might be worth taking a look at other self-service flow builders like the kind commonly used in marketing & analytics, where you set up a customer journey tracking page to page and write different rules depending on it, or where you set up an email drip campaign based on various configurable criteria.

The more generic and less usage-specific version of that is something like Zapier (for non-devs) or Make.com (for devs).

With that sort of abstraction, I guess your devs end up making a rules engine with a GUI and a bunch of modular nodes and integrations, like "if marketing software sends this webhook" or "send transactional email" or "increase customer value in CRM" or "notify staff to call this person", etc. that the powers that can then clobber together in whatever way they like.

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.

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.

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.

Stories that might help.

Back in the 1980s I was tasked with writing a system to use a handheld computer to track the manual inspection of Fire Equipment (Extinguishers, Hoses, etc) at various locations across fossil fuel based generating stations.

The very first version was hard-coded to the questions they supplied. My initial estimate was 1 month, it took 2. It met the requirements we agreed to, but it was totally unusable. Any changes to the questions required changes to the source code.

I ended up providing them with a set of forms they could use to edit questions. (This is back in the days of MS-DOS, so it was all in a TUI). To handle the ability to actually add/remove questions, I provided a set of choices for question types (Yes/No, or a number)

Then I provided 2 options, the step number to go to if the right answer was given, and the step to go to if the wrong answer was given.

It wasn't perfectly safe, they could jump to a non-existent step number, but it was easy to comprehend, so they didn't have issues fixing their own errors.

It worked well enough to set up for 10 other stations, and paid my bills for a few years.

---

Another time, the Account Managers at the Consulting Firm I worked at wanted a number of reports, all of the same general format, but with specifications that varied all over the map.

I built an SQL Query generator for them in Microsoft Access, that built (based on their selections) and showed (and allowed them to directly edit) the resulting SQL query. They were then able to cut/paste and save the queries that they liked, and build new ones on the fly.

---

If you can build a tool for them that lets them define some event, then a series of steps that should happen afterwards... they can manage the business logic directly.

Your task isn't to make it perfectly safe, but transparent enough so they can understand and build a mental model of how it acts, so they can manipulate it safely.

They need to be able to see the current rules, and perhaps even play with them in a reversible way, to test out new ideas.

I’ve worked for companies whose processes resemble what you described. It wasn’t bad at all. Things were delayed, sure, but it wasn’t a big deal (I never worked extra hours). I actually enjoyed it because it was pure joy to implement features with unclear requirements because that gave the engineers maximum flexibility (if something wasn’t implemented as needed, we would just say “alright, we’ll work on those new requirements, no problem, another sprint will be needed, though”

On the other hand I have worked for companies with a strict software development process. I’m not talking about waterfall, but agile: the systems were so over engineered that it was very difficult to write code (and it was an awful experience). Everything was done by seniors who left the company some time ago. You couldn’t really complain if you needed more time to implement something because our PMs were very clear about the requirements (so, if delays exist that’s not on them), and the code was written following good practices and standards (so again, if delays exist, is not because of the state of the code base).

I prefer to work for chaotic companies for a couple of years: more flexibility (so I can actually enjoy writing code) than for companies with obsessive practices.

I'll dust off some old replies:

On "How to properly manage a product roadmap": https://news.ycombinator.com/item?id=22827841

On "Should you listen to your customers": https://news.ycombinator.com/item?id=26814150

On "How to effectively get feedback from users": https://news.ycombinator.com/item?id=24971875

These mainly delve into extracting the job to be done, avoiding the XY problem, and looking at actual user behavior (actions or lack-thereof aka "non-consumption") to turn into issues/tickets to solve real problems as opposed to imaginary ones. You can even encode these in issue templates / ticket templates to avoid having frivolous feature requests or unimportant/non-urgent bugs and focus on things with high frequency and/or severity. i.e: product management.

Now, for the engineering side of it...

On "How do you develop internal tools for your organization?": https://news.ycombinator.com/item?id=29061808

The above link shows the inception of our product around a plugin architecture.

More on that: https://news.ycombinator.com/item?id=25186586

The design principles I had set and enforced with iron fingers. The fist of someone who presses on keyboard keys may be weak, but his fingers are ruthless.

https://news.ycombinator.com/item?id=29397405

One way to go about this is to improve the way you build product (product management, everyone is involved) or push for that, then get the engineering to deliver that in ways that make it easy to add/remove features, integrate with users (in the abstract sense, they could be humans or other systems), onboard developers.

Other posts you could cherry-pick from can be found here: https://news.ycombinator.com/item?id=40482961

The naming thing has been handled since forever - use a code for the field name and display the business value associate with it.

The business logic understanding has been handled, but rarely implemented. Any technical system should be built off of a business system. The business should be able to define their business process maps and data points exposed in each step of the map. Most systems will still need devs to implement this unless you go with some no-code/low-code process map system.

Working on teams large and small, it's an effort. Larger companies block chunks of time to discuss this subject. Start-ups prioritize customers. One suggestion is to take ownership over tackling tech-dent or documentation. Express to your immediate team what you want to accomplish and provide some generic process to implement. It's never easy but make the effort to at least attempt solving this. Good luck!

A bowl of word salad, clickbait title and expectation to get some real answers from HN community, really?

Is considered ‘short work’? What does that mean?

You need to have a conversation with your colleagues about how much capacity your development team has.

> 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.

Then don’t maintain it and just let it fail. Maintenance requires time and effort which costs money that someone has to pay for. If the customer/client/employer doesn’t want to pay for it then just don’t do it. Don’t be soft about this. Someone pays for this deliberately or it does not happen. If they feel emotionally conflicted they can go fuck themselves until business failure and lawsuits become the new norm.

Now, it is your responsibility, as the developer, to achieve competency. If the cost of maintenance exceeds a given percentage of total labor then one of two things must happen.

First, is resolution. Solve for the problem by proposing refactoring as a new feature. If they don’t want to pay for this then continue to let Rome burn.

Second, is ownership. Someone needs to take ownership of these expenses. I mean financial ownership on paper. That person(s) will be the one best positioned to address the concerns of maintenance, because maintenance costs money. Lowering the cost of maintenance requires research and measuring things. If nobody drives that deliberately it will not happen. If you as the developer cannot deliver the labor to achieve this then you should be replaced by someone who can.

That is all you need to know.

Take ownership.