Oh my poor business logic • Hacker News Board

Re: Oh my poor business logic

#131

Post by rednafi » Wed, Nov 08, 2023, 8:00 PM UTC

crabbone wrote: post #99

lmm wrote: post #22

Developers can focus on the business logic when they're close to the business. Look for places where you sit close to the business people, talk to them a lot, maybe even talk to customers. Where you're part of a team that has a responsibility of delivering product X to customers rather than a team that has a responsibility of doing things that use technology Y. The more organisational layers you have between you and…

Where I've seen this problem to be the most acute, it's not because of organizational disconnect -- it's the lack of domain knowledge on the part of the programmers. Medical software, for example, is ripe with examples of how programmers are completely clueless about clinical applications and implications of whatever they are doing. There's probably no other field where programming was misapplied as often and failed…

Until very recently, I used to work in the healthcare industry before switching to a different one. I only got into it because it was hip during covid, until it wasn’t.

The pay is bad and developers are treated like commodities by the upper management. You are expected to understand all the context around building products and at the same time, chase deadlines in every sprint. This usually happens because the business people have no idea how to run a tech company.

Also, the products are usually fraught with technical debt and no one wants to work with the codebase because working on that crap for a longer period of time will just make them unemployable. Healthcare tech is garbage for a reason.

There’s a disconnect between product owners and the engineers working on the product. Smaller teams can usually avoid it if less cross team communication is required to build and maintain the product.

Re: Oh my poor business logic

#132

Post by rednafi » Wed, Nov 08, 2023, 8:03 PM UTC

bruce511 wrote: post #13

>> There must be a middle ground where developers can focus on the core business logic that yields the most value without incurring technical debt and making the development process a nightmare. I don’t have an answer for that, nor have I worked at a company that found the perfect balance. Plus, I’m not a technical lead, manager, or business owner. So if you are one of them, I’d love to hear how you or your organizat…

>>> I'm lazy, and I'm not interested in writing it all again in some new language. So we haven't done that. I'm lazy, so I'm not interested in re-architecting it every 5 minutes. I'm lazy so i prefer simple, maintainable, easy to read, code over cleverness.

Love this.

Re: Oh my poor business logic

#133

Post by rednafi » Wed, Nov 08, 2023, 8:07 PM UTC

safety1st wrote: post #46

bruce511 wrote: post #13

>> There must be a middle ground where developers can focus on the core business logic that yields the most value without incurring technical debt and making the development process a nightmare. I don’t have an answer for that, nor have I worked at a company that found the perfect balance. Plus, I’m not a technical lead, manager, or business owner. So if you are one of them, I’d love to hear how you or your organizat…

As a dev turned entrepreneur one thing I will do when selling projects is talk to clients about software as a depreciating asset. While there are some limitations to the comparison this framing makes sense to business people in general, especially well with finance or operations departments, and can work with internal stakeholders too. The sources of the depreciation are tech debt and general turnover/churn in the me…

This is quite astute. Love the car analogy. Makes thing quite tangible while explaining the concept to the non/semi-technical upper management.

Re: Oh my poor business logic

#134

Post by rednafi » Wed, Nov 08, 2023, 8:09 PM UTC

danbruc wrote: post #49

In principle, at least for business applications, the middle ground is something like low code - data access, UI, user management, authentication, logging, auditing, ... all taken care of already, you make the data model and business logic. In practice this works up to a point, when you have requirements that do not fit the model or capabilities that the creators of the platform had in mind, when you have to start fi…

Surprisingly few numbers of businesses are fortunate enough to land on the wtf code land.

Re: Oh my poor business logic

#135

Post by rednafi » Wed, Nov 08, 2023, 8:17 PM UTC

Michelangelo11 wrote: post #122

I agree with this, but the article feels like it's talking about a world that no longer exists (or is rapidly ceasing to exist). Questions like "should salaried engineers focus on code quality at the expense of business goals" are a ZIRP phenomenon, i.e. relevant at a time when companies were hiring engineers just to prevent competitors from hiring them and when graduating from a boot camp was all it took to land a j…

You’ll be amazed at what goes on in some of these multi billion dollar companies. Why do you think the mass tech layoff happened? There are still a ton of coasters in large companies that didn’t get affected by the last layoff spree but are responsible for the next one.

Re: Oh my poor business logic

#136

Post by rednafi » Wed, Nov 08, 2023, 8:21 PM UTC

default-kramer wrote: post #117

gspencley wrote: post #104

I would like to start by teaching developers what business logic IS, and how to separate it from the other "layers" of software design. I can't count the number of applications I've seen that have no clearly defined "place" for business logic. So you see it buried in views, state management, persistence, databases (I'm looking at you, Postgres functions and stored procs), services, controllers ... anywhere and everyw…

I mostly agree with you. But I'd guess that at least 10 of those 100 developers might say something like "business logic belongs in framework-agnostic pure functions, unless you have a good reason not to." And many of the remaining developers would say "what is a pure function?" I'm not claiming that FP is always the answer, but it's a great technique that somehow is still very under-utilized despite being enshrined…

I love FP; at least some aspect of it. But it’s not popular because it’s not the panacea that the evangelists want you to believe. Also, the community loves getting engaged into pseudo-intellectual ramblings that most people find useless.

Re: Oh my poor business logic

#137

Post by rednafi » Wed, Nov 08, 2023, 8:25 PM UTC

simonw wrote: post #7

necovek wrote: post #2

There is no "perfect balance", but you need tech leads and PMs to understand that you are aiming for a balance where your tech debt is under control and you are continuously and consistently delivering business value. So far, I've failed to verbalise exactly how I achieve that in my org, but it's a combination of strategies and tactics like timeboxing refactorings, setting new tech tryouts as experiments that you re-…

An interesting challenge I've found with the term "technical debt" is that engineers can use it as an excuse to work on all kinds of things that might not genuinely be paying down technical debt, taking advantage of situations where the people making the prioritization decisions don't have the hands-on technical experience of the codebase to evaluate if the proposed "improvement" is a good investment of effort or not…

Well, when developer productivity is measured against PR rate or number of commits, I guess this is what happens. Also, it’s debatable if someone should be managing a team of engineers if they don’t have a honed bullshit detector to catch this sort of things.

Re: Oh my poor business logic

#138

Post by rednafi » Wed, Nov 08, 2023, 8:32 PM UTC

EdwardDiego wrote: post #20

> while juniors want to ditch Celery for Kafka because the latter is hip. I'm not sure when Kafka was last considered hip. Probably 2015? Also, Celery is arse to maintain, so if you're already using Kafka, make the change. If you're not, then don't.

Kafka is great. Problem is that the celery system is working just fine and there are higher priority tasks rotting in the backlog.

Re: Oh my poor business logic

#139

Post by gspencley » Wed, Nov 08, 2023, 8:47 PM UTC

default-kramer wrote: post #117

gspencley wrote: post #104

I would like to start by teaching developers what business logic IS, and how to separate it from the other "layers" of software design. I can't count the number of applications I've seen that have no clearly defined "place" for business logic. So you see it buried in views, state management, persistence, databases (I'm looking at you, Postgres functions and stored procs), services, controllers ... anywhere and everyw…

I mostly agree with you. But I'd guess that at least 10 of those 100 developers might say something like "business logic belongs in framework-agnostic pure functions, unless you have a good reason not to." And many of the remaining developers would say "what is a pure function?" I'm not claiming that FP is always the answer, but it's a great technique that somehow is still very under-utilized despite being enshrined…

> But I'd guess that at least 10 of those 100 developers might say something like "business logic belongs in framework-agnostic pure functions, unless you have a good reason not to."

Those 10 developers might have a decent answer to the question "Where should business logic live?" (decent depending on other design considerations).

But that does not answer the question I asked them, which was "What is business logic?"

Re: Oh my poor business logic

#140

Post by atoav » Wed, Nov 08, 2023, 9:40 PM UTC

thom wrote: post #78

atoav wrote: post #61

Earlier quoted context omitted.

That is why talking is important. Get all (or a good sample of all) the people who are going to use your software and discuss a draft/UI mockup. Get them in the mood where they go wild and creative and spit out all kind of ideas. Rinse and repeat till you get a coherent picture and a list of likely additional requirements. Add potential future requirements that you could think of and keep them in the back of your min…

Yeah this sort of hypothetical paper prototyping is really useful because you can map out the whole territory you're operating in, instead of just finding a single point to work towards. I think the approach actually applies beyond just UI mockups - if you can mock out whole workflows in the business with the right stakeholders/personas represented, you can also start to build up a loose dataflow model right there, a…

I specifically did say you won't catch all future requirements this way. But you want a mechanism to catch the reasonable and likely ones.

And for the unreasonable ones you can always say: "The system we originally intended wasn't meant to do this technically. If you want to have this feature we can help you but it will cost $X and this is a entirely new project."

If a graphic designer designs a logo and the customer in the end has the idea that they want that logo as a stamp or in a black and white version ANY graphic designer worth their salt will have anticipated this. If they want a 3D animated video of the whole thing rotating that is a different thing.