Oh my poor business logic • Hacker News Board

Re: Oh my poor business logic

#71

Post by _glass » Wed, Nov 08, 2023, 10:13 AM UTC

ZaoLahma wrote: post #55

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 ex…

But isn't that something of the past? I am mostly working with systems that handle the bulk of the problem, providing process, data model, etc. And extensions are done via a specific programming language, ABAP for SAP, APAX for Salesforce, but in the end, it all ends up to be like any other software development projects, with compile time checks, etc.

Re: Oh my poor business logic

#72

Post by _glass » Wed, Nov 08, 2023, 10:18 AM UTC

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…

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 and put new things into place.

Re: Oh my poor business logic

#73

Post by liampulles » Wed, Nov 08, 2023, 10:20 AM UTC

I've found that really inquisitive, good devs tend to get bored if stuck with the same stack for a while. This in my experience is what often drives adopting shiny new things which are not needed and cause progress to grind to a halt.

I was one of these developers until I saw how my shiny decisions to failure. But it's a tricky problem with good devs who have not learned that lesson, as you don't want to lose them.

Re: Oh my poor business logic

#74

Post by danwee » Wed, Nov 08, 2023, 10:21 AM UTC

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.

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 this:

business expert -> manager -> engineers -> manager -> business expert -> manager -> engineers -> ...

Whenever the manager comes with "requests" from the business side, we end up with tons of questions because everything is half-baked. Manager goes back to business with our questions and comes back with some answers, but usually that just generates even more questions. In this way managers feel empowered. There's no way they can let the engineers just talk with business (otherwise the managers would feel like they are not contributing in anything... which is kinda right if the engineers are more or less professionals).

Re: Oh my poor business logic

#75

Post by _glass » Wed, Nov 08, 2023, 10:27 AM UTC

One thing I noticed when consulting SAP or Salesforce implementations, where the tech stack is a given, the focus switches only to the business logic, people are forgetting how important tech is. Reporting starts to be included, millions of validations are running, bringing the system down. As the tech is a simple given, limitations are not to be overcome, but rather accepted. Which often turns out funny, because it has all real-world consequences of some obscure limitations.

Re: Oh my poor business logic

#76

Post by tlb » Wed, Nov 08, 2023, 10:51 AM UTC

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've experienced this too at a bigco. A well-meaning group of UX people took on the role of conducting all user observation studies. And the studies were high-quality and statistically valid, but it took months to get observations I could have seen directly in minutes. So the recommendations were mostly about things I'd already fixed or changed.

It's much better to just talk to users and watch them work. A same-day feedback loop beats any improved study quality.

Re: Oh my poor business logic

#77

Post by wazoox » Wed, Nov 08, 2023, 10:53 AM UTC

There are several level of relationships in a company: technical, business and social. Often, management hires consultants to push for organisational changes, and most of the time social relationships are ignored because in contrast with the other two, they're mostly unwritten and implicit.

It's sort of sad and funny to see people pushing for organisational change through new internal applications deployment or new procedures and workflows, without ever tackling the human interaction factor.

Re: Oh my poor business logic

#78

Post by thom » Wed, Nov 08, 2023, 11:07 AM UTC

atoav wrote: post #61

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…

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, and also understand some of the likely articulation points of the resulting systems, just by having conversations like "what if we needed this human process to happen first" or "what if we eventually built a model to automate this process" etc.

Re: Oh my poor business logic

#79

Post by jon-wood » Wed, Nov 08, 2023, 11:16 AM UTC

ahepp wrote: post #57

gedy wrote: post #31

Earlier quoted context omitted.

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.

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.

Re: Oh my poor business logic

#80

Post by danbruc » Wed, Nov 08, 2023, 11:29 AM UTC

atoav wrote: post #61

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…

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…

This is in general hopeless, you will not be able to anticipate where the business moves over the coming years. Does not even have to be the business itself, could also be the regulatory environment or whatnot. When you decide to not write your application from scratch, you will always have the risk of running into limitations eventually. If it is low level stuff like your O/R mapper or your logging framework, that is no big deal, but if it is some high-level application or business framework, then things might get tricky.

In one of the projects I worked on there suddenly came the requirement that they need metrics on how long people were working on different screens, completely unrelated to the actual business. No big deal in general, just put some code in some base class to collect the current time on enter and on leave. But the application framework we used just does not allow this, you can not modify the base classes used for screen, you have to add code for the enter and leave event on each screen individually. It just never occurred to the people that made the framework that you might want to do the same thing on all your screens and nobody expected that we might ever need this either, until we did.