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

61–70 of 154 posts

Re: Oh my poor business logic

#61

Post by atoav »

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 mind. When everything is done you can offer those.

This might not catch all the surprise requirements, but it might catch the worst ones.

A sure way to get surprised is to do the opposite:

- don't talk to the people who use your software, but some middle-men

- just take the customers first idea as gospel and assume they disected the problem space themselves

- keep everything constrained and never let anybody get wild or crazy with ideas

- don't anticipate potential future requirements and don't let them influence your decisions ever

Of course those things don't come for free, but it is important to realize that the initial phase of a project is crucial also for the impression your shop will leave behind. If people feel they have been heared and had a chance to come to a shared understanding with you, they are less likely to view your software in an unfairly harsh light later on. They will remember this and will hire you for the next thing.

Re: Oh my poor business logic

#62

Post by toyg »

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.

Often it's because getting involved on the business side means doing a lot of politics. Is this problem more urgent than that problem? Who will take credit for solving this problem? If I solve this problem, will they fire half the people who currently solve it manually? If I solve that problem, will it empower a certain scumbag VP who's been clamouring for it? Etc etc.

Codemonkey doesn't want to be involved with all that shit.

Re: Oh my poor business logic

#63

Post by d--b »

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

- why can’t we get anything done?

One has to realize that this is how it works, and be at peace with it.

Re: Oh my poor business logic

#64

Post by Tade0 »

I've found that small, focused teams are generally better at this, especially when they're close to the stakeholders and can arrange a metting to get some feedback if need be.

Unfortunately companies tend to throw people at the problem, so you get 10+ sized teams where 30% at maximum do any productive work, because the rest is either too caught up in their personal lives or too junior to pull their own weight.

I've been both part of that 30% and the rest in different projects and I've managed to flip one dev to the better side once, so it's not typically an inherent feature of a person.

Re: Oh my poor business logic

#65

Post by fragmede »

gymbeaux wrote: post #28
NAHWheatCracker wrote: post #16

Earlier quoted context omitted.

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…

It’s humorous to see your company’s seemingly-wise desire to do Agile properly shadowed by the classic attitude of “Contractors? The people we pay to do a job same as FTE? Fuck ‘em!”

Contractors != Consultants

Re: Oh my poor business logic

#66

Post by discreteevent »

"Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities. Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance." - Eric Evans

Re: Oh my poor business logic

#67

Post by creshal »

toyg wrote: post #62
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.

Often it's because getting involved on the business side means doing a lot of politics. Is this problem more urgent than that problem? Who will take credit for solving this problem? If I solve this problem, will they fire half the people who currently solve it manually? If I solve that problem, will it empower a certain scumbag VP who's been clamouring for it? Etc etc. Codemonkey doesn't want to be involved with all…

Requirements engineering can be extremely draining regardless of it.

What's that? We're three years into this six months project and you just realized again that you don't understand your own job, don't understand the legal requirements placed on you, nor your position in the overall organizational architecture? Of course we can rewrite everything from scratch for you, again. What do you mean there's no budget and it has to just work?

Re: Oh my poor business logic

#68

Post by rob74 »

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.

It boggles my mind how someone can think they can build anything useful without having a basic understanding of what the thing they are building will be used for... that's a sure-fire way to software that will be a nightmare to use (and support).

Re: Oh my poor business logic

#69

Post by necovek »

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…

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 effort (if you can have another deployment, that's ideal).

But honestly, it is engineers job to find that hard to reach balance: keep improving the code, and keep delivering value.

That's the hard part of software engineering, and we should all embrace it.

Re: Oh my poor business logic

#70

Post by rob74 »

toyg wrote: post #62
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.

Often it's because getting involved on the business side means doing a lot of politics. Is this problem more urgent than that problem? Who will take credit for solving this problem? If I solve this problem, will they fire half the people who currently solve it manually? If I solve that problem, will it empower a certain scumbag VP who's been clamouring for it? Etc etc. Codemonkey doesn't want to be involved with all…

I don't think GP means getting involved with business side decisions, just understanding the "business logic". Where "business logic" is a generic term for anything, it could also be the rules of a sport, how the competition(s) are structured etc. if you are building a sports website...
Post reply on HN