Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oh my poor business logic

rednafi.com

Post reply on HN
Print view View original

141–150 of 154 posts

Re: Oh my poor business logic

#141

Post by necovek »

NAHWheatCracker wrote: post #108
necovek wrote: post #69

Earlier quoted context omitted.

I think you are offering bad options: refactoring is something that comes with any new work. You don't have to justify it, but include it in your estimates. Obviously, the risk here is that you include non-neccessary refactoring work in it, and then people stop trusting you. And finally, there is a hack-it-together approach, but I always try to keep that outside the core product to make it clear this is throwaway eff…

> refactoring is something that comes with any new work. You don't have to justify it, but include it in your estimates. Sometimes it's too much work to do ad hoc. Oftentimes people won't go out of their way to refactor. Having the fair discussion can make it real and important. If the team can't talk about refactoring, it's an unhealthy team. Managers who want to act like maintenance of a project isn't something tha…

Let's agree to disagree.

Sure, it is everyone's job and they should certainly openly talk about it, but no manager can go and do it for an engineer.

A great engineer can find an incremental value with any refactoring they do: otherwise, they are extremely likely to refactor for the wrong future. I've seen this play out a number of times.

And the root cause is always exactly the same: engineers can't design code for the future that's not here today or at most, tomorrow. When they think they've done it, a new future comes and that code is even harder to refactor because it prematurely catered to cases that never materialized.

But that's exactly why managers need to understand and accept that refactoring is software engineering, and engineers need to do it continuously and keep delivering value while they do it.

And while CTOs, Eng Directors, architects and technical leaders might be "managers" in a sense, to me they are still all engineers, and they are the ones ensuring technical direction enables a healthy project while satisfying business goals.

Non-technical managers are there to bring clarity to business requirements, but they don't need to know exactly how sustainable technical excellence (or at least health) is achieved, the same way engineers don't need to know how user research or user testing that proves something works or not, is performed.

Re: Oh my poor business logic

#142

Post by necovek »

NAHWheatCracker wrote: post #17
swatcoder wrote: post #12

Earlier quoted context omitted.

Some of this is a product of job-hopping culture and of having boom-time teams (technical and management) with too many early-career members. Some of it is also just the perpetual back and forth of competing interests. That said, for those who do good work and develop long-term trust with long-term colleagues, addressing technical debt is often “poke at this while I sip coffee” work that get chipped away at gradually…

> When you’re having to pitch the work to someone, you’ve often already failed the pitch. Damn that stings and it's so true. > But if your peers come to trust you, then they learn not to reject a PR that cleaned up this module a little more than strictly necessary I've never had an issue where a coworker rejected a PR, even when doing a massive refactor that isn't strictly necessary. Project managers are the ones tha…

> I've never had an issue where a coworker rejected a PR, even when doing a massive refactor that isn't strictly necessary.

As an engineer, I have rejected massive refactors in unrelated PRs: heck, I have rejected massive PRs period.

They always:

- are hard to review

- bundle a bunch of unrelated changes together

- hard to accept piecemal

- risky to test and deploy

- hard to revert

- hard to pivot according to new learnings along the way

- hard to improve

- have lots of review iterations

- slow down all the other work (conflicts, remerging effort for all the other changes in flight...)

- usually "one way doors" (relates to hard to revert)

When these are done as small incremental steps where we improve one thing at a time, none of the above hold, and coupled with a good CI/CD pipeline, take less time.

I know that many engineers believe there are things that can't be done incrementally like that, but I've always been able to give them a plan for any "impossible-to-split" refactor/rewrite.

Re: Oh my poor business logic

#143

Post by default-kramer »

rednafi wrote: post #136
default-kramer wrote: post #117

Earlier quoted context omitted.

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.

Yeah that kind of stuff can definitely scare people away. I don't know what a monad is and I've stopped pretending to care. For me immutability and pure functions are the only important concepts; everything else is a bridge too far for practical corporate use. Still, I think that while null is commonly called "the billion dollar mistake", I wonder... I think that going back in time and making C# and Java immutable-by-default would have a bigger impact than adding null-safety. Maybe not a panacea, but FP does seem to set a pretty acceptable lower bound on how terrible a codebase can get in my experience.

Re: Oh my poor business logic

#144

Post by default-kramer »

gspencley wrote: post #139
default-kramer wrote: post #117

Earlier quoted context omitted.

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?"

You're right. And I realize I can't answer the question. But I wonder how much it matters? If a colleague and I disagree on whether some authorization logic counts as business logic or not, what is at stake?

Re: Oh my poor business logic

#145

Post by gspencley »

default-kramer wrote: post #144
gspencley wrote: post #139

Earlier quoted context omitted.

> 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?"

You're right. And I realize I can't answer the question. But I wonder how much it matters? If a colleague and I disagree on whether some authorization logic counts as business logic or not, what is at stake?

Business logic is often the type code that changes least. If it is well designed, isolated and organized your business logic can survive UI changes, framework changes, stack changes, database vendor changes and all sorts of other "infrastructure" change. If you can't identify that "layer" from the others, then business logic will make its way into all sorts of areas that make change harder. And the ability to change is the very value that software has to offer in the first place. If it didn't need to be resilient to change then we could stick with fixed circuits which are far less expensive to build and maintain.

Re: Oh my poor business logic

#146

Post by thom »

danbruc wrote: post #128
thom wrote: post #124

Earlier quoted context omitted.

I'm not sure what you're responding to. I'm suggesting you specifically model how things might change to give you a better chance of identifying the right articulation points for your architecture - as in, what if I have to drop one side of this because our assumptions were wrong, but I don't want to lose _everything_? You can't predict the future, but you can built at least _some_ flex into your business and platfor…

See my comment on the sibling comment, I was talking about the trade off between speed and flexibility.

A tradeoff that’s much easier to reason about with more information.

Re: Oh my poor business logic

#147

Post by cavisne »

yeswecatan wrote: post #35
cavisne wrote: post #19

There is a new paper out from Google which seems like an interesting approach to get out of microservice hell https://sigops.org/s/conferences/hotos/2023/papers/ghemawat....

This is an interesting paper and one I would never have found on my own. How did you come across it?

Twitter, I think it is pretty new. The lead author is a very well known engineer.

Re: Oh my poor business logic

#148

Post by safety1st »

_glass wrote: post #72
safety1st wrote: post #46

Earlier quoted context omitted.

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 very valid and well written. One point I like to stress is the external context I often observed for why it is deprecating. As a company grows initial architectural decisions become more of a burden. So even though some software is running just fine for the specific business case, your new stack can do 80% but also a lot more. This is my way of selling modular solutions, where you can easily take away things…

Yes, that's a great point. Once we think of a software system as a depreciating asset we start to see a number of factors which are beyond our control. Another example when we're building web apps is that the competitive landscape has changed -

* 15 years ago no one expected their website to work well on a phone, or serve up much in the way of streaming video.

* 10 years ago no one was expecting that a server should respond in under a second, aka Lighthouse's TTFB, and the concept of say a "Largest Contentful Paint" did not exist.

We can go on forever, so what has happened is that all the practices and expectations within the industry have been redefined (occasionally even for good reason!). To stick with the car analogy, you don't expect much in the way of self-driving features from an older car... hell power windows didn't even become ubiquitous until the 1990s.

So maybe we just can't get a great TTFB and LCP out of our old dependency stack which existed before those concepts were really a thing, and there you have an example of why a rebuild will probably continue to be a "when" rather than an "if" for years to come.

Now we can frame the discussion as "let's partner up to ensure we make the best use out of this system and extend its life as much as is reasonable," which doesn't have to be an adversarial discussion.

Re: Oh my poor business logic

#149

Post by flowinghorse »

Just note that any organization is quite complex, and surely at different times different people in an organization have different purposes, and they may have different understandings if they share the same purposes. So it is pretty common that everybody's actions, understanding, and purposes are not coordinated.

The purpose of an organization is never simple. From Hebert Simon's :

> The survival and success of organizations depend on their providing sufficient incentives to their members to secure the contributions that are needed to carry out the organizations' tasks

Post reply on HN