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

51–60 of 154 posts

Re: Oh my poor business logic

#51

Post by valenterry »

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…

If engineers do that, then they don't need to use the term "technical debt" anyways. They can just claim a feature takes twice as long and then play around 50% of the time.

So in reality, it's not "technical debt" that's the issue, it's that engineers don't have the right incentives from the beginning.

Re: Oh my poor business logic

#52

Post by papercurt »

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…

The people at pivotal labs I got to know were amazing and I learned so much from then. However, there was also a ton of cargo cult going on among them and the code was far from brilliant.

In the End they couldn't change much of my company's approach to software development. Managers mostly want to be fast like a Silicon Valley startup only if it does not mean they need to change anything in the organisation. Anyway, years of semi-successful software projects are more likely to bring a change...

Re: Oh my poor business logic

#53

Post by jonathanlydall »

klysm wrote: post #30
jonathanlydall wrote: post #29

The startup (bootstrapped, non-US based) I work for creates a developer productivity tool which gives you high quality architecture “for free”, allowing you to instead focus on those bespoke un-automatable business rules. We essentially aim to solve the author’s stated issue here.

I'm very skeptical that's high quality for all use cases. Architecture is a huge trade off space and what's right for a particular product is most certainly wrong for another.

Absolutely, you choose or create the architecture or architectural components which make sense for your particular situation/requirements. After all, there is no one size fits all architecture, there is instead a choice of trade-offs.

Re: Oh my poor business logic

#54

Post by al_borland »

giantg2 wrote: post #23

I hate both types of organizations. I think I hate the rapid tech switching even more than the business focused one. There's a lot to hate about languages like COBOL, but honestly it looks awesome create neat code with actual documentation and design documents, that will just work for decades with minor upgrades and changes. Durable systems are gone. Longterm support is 12-18 months. Iterate or die is how it works no…

I see no point in automating anything if I'm expected to re-write it every year. If they are going to pay me to do that, they might as well just pay someone to do the work manually. It would probably be faster and cheaper than the illusion of time savings we're getting from reimplementing the same solutions year after years against our will.

The best things I've done are the things I've never told management about. I make something, it works, people use it, and I don't have to touch it again for years. When I do, it's a minor change that takes 5 minutes. Anything coming from management is a multi-year project that requires hundreds of hours of meetings and at least 60 devs across a dozen teams... all to make something that 1 person could do in a few weeks if they were left alone and didn't have to conform to their overly complex frameworks.

Re: Oh my poor business logic

#55

Post by ZaoLahma »

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…

... and this is when the development company (architect, technical director, ...) decides to extend the "data" models to the point where you've invented a programming language in XML. A programming language too advanced to use even for the programmers that invented it, let alone the "no code" people that it was intended for. A programming language with all of the complexities and none of the tooling that you would expect from a programming language, where failures are caught in runtime since you have no compile time checks of the XML that you throw at it.

Next step is, of course, to extend the XML validation to make sure it conforms to your application's expectations. And suddenly you have invented a compiler as well.

Re: Oh my poor business logic

#56

Post by j-a-a-p »

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…

Yes, reminds me of about 25/30 years ago when low code was at its high. Back then there were strict guidelines where to put business logic (client, server or both), how to name them. Everything had to originate from the model (model driven development).

Since then the developers took over and killed waterfall and 4GL in the process.

Re: Oh my poor business logic

#57

Post by ahepp »

gedy wrote: post #31
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…

You'd think this is non-controversial, but have worked at places where product and UX act as gatekeepers and don't want engineers involved with the problem solving. They'll "figure it out for you" and then spoon feed Jira tickets and Figma mockups to devs.

I also agree that I prefer to work this way, but it's crazy to see how many developers have an "I just want to code, I don't want to think about business problems" mentality.

In some ways I respect their devotion to pure technical craft. Personally, I'm not talented enough at the technical aspect to make up for ignoring business needs.

Re: Oh my poor business logic

#58

Post by PH95VuimJjqBqy »

swatcoder wrote: post #8
chefandy wrote: post #6

Earlier quoted context omitted.

I think the author was using hyperbole to illustrate two problematic organizational tendencies. I could say something like "I see two kinds of drivers in the northeast: ones that drive like they're fleeing a bank robbery in a stolen police car and others driving like they're piloting a parade float carrying a human pyramid." I think it's obvious I'm not saying literally all drivers in the northeast fit into one of th…

I’m sure that’s what they were trying to do, but their argument only carries weight in the context of those hyperboles. In your example, it’d be like continuing the essay to argue that people should really try driving like they were just in a plain old consumer car. The thing is: that’s essentially what everybody is already doing in the real world, and so you’ve not contributed anything with your argument.

> I’m sure that’s what they were trying to do, but their argument only carries weight in the context of those hyperboles.

That's only true if you struggle to understand ideas vs expression.

Re: Oh my poor business logic

#59

Post by j-a-a-p »

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…

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

Totally agree. However be aware that there is a tradeoff. I have seen too many projects where business logic was informally embedded throughout the codebase. Such that only the original developer could make sense of it.

Re: Oh my poor business logic

#60

Post by rahkiin »

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…

Thank you, this is very insightful and I might try this to explain software.
Post reply on HN