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

101–110 of 154 posts

Re: Oh my poor business logic

#101

Post by danbruc »

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…

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.

Re: Oh my poor business logic

#102

Post by cromulent »

j-a-a-p wrote: post #100
CPLX wrote: post #82

Earlier quoted context omitted.

Genuine question, what were the low code frameworks that were popular in the late 90’s that you’re referencing here?

Forgot most of that, I consider this 'enterprise period' in my life as pretty boring. There was one product really popular then, but forgot the name. Sorry. A product I personally know is Oracle Designer . This could generate fairly complicate applications (like master-detail-detail layouts) based on the ERD. Another product I also forgot it's name, was considered very good, but used only within the IBM ecosystem. Fu…

RPG?

Re: Oh my poor business logic

#103

Post by vsareto »

jon-wood wrote: post #79
ahepp wrote: post #57

Earlier quoted context omitted.

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.

My biggest frustration is the people who refuse to get involved with any of the process of defining requirements, but then when the requirements arrive moan about how they're stupid requirements and won't get the job done. You can't have it both ways.

It's because defining requirements is someone else's job, so if you get involved, you will be doing part of their job while you might already be working at your capacity.

The Agile style user stories that often lack technical details because the author doesn't know enough about the technical details means the developer is the one actually writing the requirements (usually as they are doing the work).

Re: Oh my poor business logic

#104

Post by gspencley »

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 everywhere. Impossible to test, impossible to reuse, waiting for someone to extract and isolate it but no one seems capable of even recognizing it for what it is.

I think if you were to ask 100 developers to define "business logic" you would get 100 different answers. That's the first problem to solve.

Re: Oh my poor business logic

#105

Post by pas »

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…

it's clear there's no budget for maintaining that disciplined layering ... (see #3 on the list from https://news.ycombinator.com/item?id=38188689 )

to have a sacred place for business logic it'd require a nice interface, maintaining that has an overhead compared to "can't we just intercept the request at ... "

Re: Oh my poor business logic

#106

Post by pjc50 »

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)

This is incredibly difficult, valuable work that so few organizations dare to do. Often the answers are unpopular.

Re: Oh my poor business logic

#108

Post by NAHWheatCracker »

necovek wrote: post #69
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…

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 that should ever be their concern don't deserve a paycheck.

> But honestly, it is engineers job to find that hard to reach balance

This attitude is bullshit. It's everyone's job. High level balance is more of a concern for management. Low level balance is the more of a concern for engineers. High and low level balances can work for or against each other. Management that just pushes their responsibilities down the hierarchy aren't pulling their weight.

Re: Oh my poor business logic

#110

Post by gustavus »

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.
Post reply on HN