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

111–120 of 154 posts

Re: Oh my poor business logic

#111

Post by NAHWheatCracker »

mdekkers wrote: post #47
NAHWheatCracker wrote: post #9

Earlier quoted context omitted.

I've been quite frustrated that the term "technical debt" is so misused. It feels like project managers immediately assume technical debt means "the developer wants to play around". I only use it when it means "the features you want can't be implemented, correctly, and under the time constraints". For what it's worth, I shy away from the term and talk more about approaches and outcomes. It's still baffling when I giv…

The issue here is offering up #3 “It will be late, broken and other features will break” means you are not delivering anything of value, so it is not an option. Offering #3 just communicates “this can be done at a cost that is not relevant to you” as opposed to “there is no way to achieve the stated outcomes” Offering #3 is absolutely not a business or management problem, this is something you are doing wrong.

Management that sees 3 options an picks the objectively worst outcome is absolutely the problem.

I'm not sure if you could ever see management as the problem.

Re: Oh my poor business logic

#112

Post by rednafi »

d--b wrote: post #63

Well the middle ground does exist and it is mostly just a blend of the two problems. Most companies I worked tend to oscillate between these two extreme: - why can’t we get anything done quicker? We need to stop refactoring everything all the time! 6 months later: - why is everything breaking all the time? Why are engineers complaining that the code is shit? We have to stop and start again on cleaner bases. 6 months…

This is far better than picking one extreme and sticking with it until the product dies!

Re: Oh my poor business logic

#113

Post by Aqueous »

High level architects should focus primarily on creating a system architecture that is designed to incrementally and composably add functionality.

This often means adopting some sort of overarching architecture that nudges people towards composable implementations. For write-heavy, highly stateful systems with complex business logic, this means using something like a workflow engine where you can simply declaratively add tasks and conditions to pre-existing DAGs while being confident the existing workflow will not fundamentally change. To create new functionality, it's often enough to use existing functionality as a drop-in template. Duplicate and add / remove - no need to worry about what's there because you're not touching it.

For read heavy systems thinking about composition at the very highest levels is also very important. This allows engineers to easily add functionality without being concerned about breaking what's already there.

Always favor additive models over models where updating existing functionality is the norm. This means junior engineers can "color within the lines" so to speak, and the risk to the rest of the system is low.

Would also emphasize that while unit testing is often useful for the individual developer working on a piece of code, but as far as ROI, end-to-end integration testing has the most bang for the buck. If you have the full endpoint tested, for instance, from end-to-end, including database writes, your confidence level goes up by an order of magnitude when you have to modify that functionality. If you have to choose between investing in extensive unit testing and extensive end-to-end API or contract tests, always choose the latter.

Re: Oh my poor business logic

#114

Post by thenobsta »

FuriouslyAdrift wrote: post #97
danwee wrote: post #74

Earlier quoted context omitted.

> The more organisational layers you have between you and the customers - architects, business analysts, and the like - the more disconnected your work will be from the business value. In every company I have worked for in the last 10 years, the layer in between business experts and software engineers has been always: the manager (either product manager or eng. manager). It's a bottleneck. The flow usually goes like…

When I worked disaster recover and continuity, we had to map every business process. We would make one map from the info the managers told us and one map of the actual processes by talking to every single employee involved. We frequently found critical processes no manager knew about and also that some random secretary was the focal point for entire departments (mundane processes no one else wanted)

Whoa, this is unsurprising, but surprising/unfortunate.

I'd love to read a tutorial of how mapping every business process is done in practice. Do you have any pointers?

Re: Oh my poor business logic

#115

Post by ajkjk »

nvella wrote: post #41
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....

I've only read the abstract, but hasn't this been achievable for at-least the last twenty years with dependency injection? I've seen time and time again developers conflate microservices with the general concept of service abstraction and separation-of-concerns. These things have existed before microservices, and will continue to exist. A good DI implementation allows for one to define these business services as inte…

This isn't really DI. From skimming, it is sort of.. cross-machine DI.

Re: Oh my poor business logic

#116

Post by Tainnor »

Aqueous wrote: post #113

High level architects should focus primarily on creating a system architecture that is designed to incrementally and composably add functionality. This often means adopting some sort of overarching architecture that nudges people towards composable implementations. For write-heavy, highly stateful systems with complex business logic, this means using something like a workflow engine where you can simply declaratively…

> Would also emphasize that while unit testing is often useful for the individual developer working on a piece of code, but as far as ROI, end-to-end integration testing has the most bang for the buck. If you have the full endpoint tested, for instance, from end-to-end, including database writes, your confidence level goes up by an order of magnitude when you have to modify that functionality. If you have to choose between investing in extensive unit testing and extensive end-to-end API or contract tests, always choose the latter.

It's not so clear-cut, unfortunately. Extensive end-to-end tests can be very hard to setup, can be flakey, can take forever to run (especially if you do it on every change), etc.

I agree you should have some layer of automated end-to-end testing (and not enough people do), but in the end, I think you have to work towards making the system as compositional as possible, so you can also test things extensively in isolation - the end-to-end tests then serve to make certain that the individual pieces fit together, but don't hit all the edge cases.

Re: Oh my poor business logic

#117

Post by default-kramer »

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 in popular frameworks like React (I think). I don't mean to criticize developers who are unaware of FP - I graduated in 2008 but didn't learn FP until 2014, and I still can't believe that I was ignorant of it for so long. And I can't believe how many developers are still ignorant of it. Unless I'm wrong and FP actually sucks, there is an education problem.

Re: Oh my poor business logic

#118

Post by latchkey »

gustavus wrote: post #110
latchkey wrote: post #10

> 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. Personally speaking, the best place that I've worked at that mostly solved that balance, was Pivotal Labs. Technically, it was Clo…

Can I just take a minute to thank you for CloudFoundry, it seems like it was what PaaS really should be and when one of the organizations I was contracted with moved to AWS one of the things we realized was that there really was nothing like CF anywhere else. Thanks for your work if you worked on CloudFoundry then you probably know some of the people on my team.

That's really nice to hear. When I was there, it was super early into the acquisition and CF was a shit show. For context, this was even before Docker was announced. The people who stayed on eventually rewrote most of it and turned it into a much better product. This was a great example of using the Pivotal process to do good.

Re: Oh my poor business logic

#119

Post by atoav »

danbruc wrote: post #101
thom wrote: post #78

Earlier quoted context omitted.

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…

This is no problem for the initial version but businesses and the environment they operate in change, you are in general not going to figure out what you will need ten years down the road. And then it really depends, maybe everything is fine, but maybe you also made choices early on that allowed you to save time and the price of limited flexibility and this eventually bites you.

What you say is correct. But there is literally no way to figure out what will be needed 10 years down the road using any kind of methodology. If you are clever you try to use stable things, technology that is likely to be an ok choice years down the line and maintain an architecture that is easy to maintain and modify.

But if your software managed to survive a decade of good use without any major issues I'd already count that as a job well done.

Re: Oh my poor business logic

#120

Post by gymbeaux »

granshaw wrote: post #33
gymbeaux wrote: post #27

I’m on a sabbatical because I find myself very jaded by the industry, more or less for the reasons stated in this article. What I tell people is something like “I LOVE building stuff with code, but lithe EVERYTHING ELSE.” Writing code may be better suited as a hobby for me… after all, I have the most fun with side projects… but then, as most of you can probably empathize with, how will I make the sweet, sweet six fig…

Sounds like freelancing/consulting might be right up your alley. Maybe building mvps or working on relatively new products or codebases. Charge for your time and no pretend work. Yes, you’ll have to find clients. No, there is no perfect alternative to the “sweet six figures”, something’s gotta give, but you gotta start somewhere

Yep, I’ve done some freelancing over the last few years. I like it, but it’s hard to do that and a full-time job at the same time. Obviously the issue is getting enough work when you’re not normally employed, and when you are normally employed, the issue is not getting too much work. Clients like stuff ASAP and telling them an MVP will take 3 months because you’ll only be working on it 8 hours/week doesn’t go over well. The clients I’ve had are understanding but they all eventually want me to quit my job and come work for them, either as FTE or still a freelancer.
Post reply on HN