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

41–50 of 154 posts

Re: Oh my poor business logic

#41

Post by nvella »

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 interfaces and implementations within an initial monolith, and then trivially reimplement those interfaces against an API or RPC when it comes time to scale. Interfaces can be separated out into a common library which can be referenced in all parts of the system. I am simply curious as to why this has been so staunchly avoided over the past decade of microservices hype.

Re: Oh my poor business logic

#42

Post by closeparen »

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…

Good judgement about how to allocate your time (and the team's) is one of the most important skillsets of a senior or staff-level engineer.

Re: Oh my poor business logic

#43

Post by ehnto »

gymbeaux wrote: post #25
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…

I really like that “X vs Y” example. I was just on a team where we were estranged from the business folk who would supposedly be using our products and it very much felt like a “Y”, where my boss cared much more about the tech stack than the value (if any) we could deliver to the users. Suffice it to say the team was cut in a round of layoffs. I had fun working with things that I normally wouldn’t work with (eg Neo4j…

I have come to not care much about the tech stack, I work with all sorts. But by extension I grow weary of of dealing with technical problems that are only tangential to the business problems.

Incidental complexity it can be called. Problems outside of the core business domain or problem you are solving. Like, you can't get the data in the right format because your version of a DB library doesn't support it, something like that. I want the tools to get out of the way so I can focus on the problems.

I bring that up because I find certain ecosystems respect that a lot more than others. Some people are busy building Jenga towers of abstractions because coding is fun, but many of us are knee deep in the business domain and just want the tools be clear and easy.

Re: Oh my poor business logic

#44

Post by p1necone »

NAHWheatCracker wrote: post #16
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…

I worked at a health insurance company 6 years ago where they brought in a group from Pivotal for a week and we worked with them to see how they ran a Scrum team. I was amazed. The Scrum master wasn't just some busy body manager who only ran stand-ups, he was constantly floating around throughout the day helping people out. We had 4 developers and 4 consultants, so we mostly paired up and that was super productive. P…

> constantly floating around throughout the day helping people out

I unironically love being distracted by other peoples problems. Usually the person giving me the work I'm really supposed to be doing gets annoyed at me for it, I'd love it to be my actual job.

Re: Oh my poor business logic

#45

Post by quickthrower2 »

A good balance comes when both employees care about business decisions e.g. "is it worth spending 3 months of the teams time on X?" and vice versa non-engineers are aware of technical debt and why teams are trying to 'pay it down'. The ideal situation is when there is someone or a group of people who can take in all the information and make decent business decisions. After all - the codebase and it's maintainability is a part of the business (just like a well maintained oil rig vs. a bad maintained one impacts the business). It is just not as visible as managers can't walk around and eye up the code as easily as see cracks and rust in the building work.

Re: Oh my poor business logic

#46

Post by safety1st »

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 method and process within an industry/vertical (like if you built a web app in 2002 based on ASP.NET, it's pretty tough for that to be a lively project today).

We know there are systems out there that have been running well and doing their job for 30 years, and there are systems that need to be replaced/rewritten from scratch every couple of years. Which one do you want to buy/fund/budget for?

If the customer or stakeholder only cares about a two year horizon you approach the project one way. If they say they want this thing to be firing on all cylinders 10 years from now then we approach it and price or budget for it differently. When you talk like this it doesn't sound too weird to introduce the idea that we should do an annual tune-up to a system that they don't want to have to replace until 2035. The tune-up is how you get 15 years of life out of your intellectual property instead of 10, this is how you sell time to pay down tech debt. The eventual rebuild is also part of the discussion (not if it will happen, because it will. But when it will happen is something we can influence, so the framing can be, would you rather do an expensive rebuild every 10 years, or do it in 15-20 because you paid for a regular maintenance along the way?).

Boom now in their head this software you're writing is like a car. Everyone understands cars. A car has a lifespan. If you didn't go to the mechanic and do your annual scheduled maintenance and the car breaks down, that's what you get for being cheap. Like I said big ops and finance departments actually really like the idea of a tuneup that prevents the car from breaking down. They're used to thinking about that with lots of physical assets anyway. A marketing department at a startup maybe not so much but their time horizon is usually short anyway.

Re: Oh my poor business logic

#47

Post by mdekkers »

NAHWheatCracker wrote: post #9
simonw wrote: post #7

Earlier quoted context omitted.

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…

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.

Re: Oh my poor business logic

#49

Post by danbruc »

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 fighting the platform, then you are right back in wtf code land. When you decided which platform to use, you of course evaluated this and made a good choice, building the first version worked nicely. Now you have a running system and want to extend it, now you are getting the more unusual requirements that were not important for version one and therefore not taken into account when making the platform choice, now your nightmare starts.

Re: Oh my poor business logic

#50

Post by T1tt »

gymbeaux wrote: post #25
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…

I really like that “X vs Y” example. I was just on a team where we were estranged from the business folk who would supposedly be using our products and it very much felt like a “Y”, where my boss cared much more about the tech stack than the value (if any) we could deliver to the users. Suffice it to say the team was cut in a round of layoffs. I had fun working with things that I normally wouldn’t work with (eg Neo4j…

i would say theres engineers arent set up close enough to customer issues; theres too many layers in between
Post reply on HN