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

121–130 of 154 posts

Re: Oh my poor business logic

#121

Post by tstrimple »

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 work in consulting and corporate dysfunction is how we make money. The disconnect between "business" and "IT" is at the core of most of these engagements. Because of the relationships between funding and ownership, the relationships often become downright antagonistic. In the latest example, we were working with the IT side of a company trying to get connections to the business side because we know that solving those sorts of issues is the best path for real improvement. During this process the business went out and hired their own consulting company to work on things instead. It's absolutely insane what happens inside of multi-billion dollar companies.

Re: Oh my poor business logic

#122

Post by Michelangelo11 »

I agree with this, but the article feels like it's talking about a world that no longer exists (or is rapidly ceasing to exist). Questions like "should salaried engineers focus on code quality at the expense of business goals" are a ZIRP phenomenon, i.e. relevant at a time when companies were hiring engineers just to prevent competitors from hiring them and when graduating from a boot camp was all it took to land a junior SWE role. Now that the engineering job market is, alas, looking a lot like other job markets, this feels like it's from a different reality.

Re: Oh my poor business logic

#123

Post by joelthelion »

I'm a manager who tries to take this middle road. But it's frustrating to see other teams on either side of the spectrum celebrated, and hard to get recognition for your small team that just gets the job done, while trying to keep an acceptable level of quality.

Re: Oh my poor business logic

#124

Post by thom »

danbruc wrote: post #101
thom wrote: post #78

Earlier quoted context omitted.

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.

I'm not sure what you're responding to. I'm suggesting you specifically model how things might change to give you a better chance of identifying the right articulation points for your architecture - as in, what if I have to drop one side of this because our assumptions were wrong, but I don't want to lose _everything_? You can't predict the future, but you can built at least _some_ flex into your business and platforms.

Re: Oh my poor business logic

#125

Post by punnerud »

BOOSTERHIDROGEN wrote: post #88
rob74 wrote: post #70

Earlier quoted context omitted.

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

Wait, I'm no programmer, How could programmer build if they don't understand that minimal business logic ?

Spoon feed JIRA tickets on what to do

Re: Oh my poor business logic

#126

Post by danbruc »

atoav wrote: post #119
danbruc wrote: post #101

Earlier quoted context omitted.

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.

What you say is correct. But there is literally no way to figure out what will be needed 10 years down the road using any kind of methodology. If you are clever you try to use stable things, technology that is likely to be an ok choice years down the line and maintain an architecture that is easy to maintain and modify. But if your software managed to survive a decade of good use without any major issues I'd already…

I think there is a tradeoff, you can pick some customizable off the shelf software or some low code platform that fits your initial needs, that will give you speed at the risk of not being flexible enough later. Or you fire up your IDE and start from scratch, do everything on your own, that will make you slow, at the very least in the beginning, but you get all the flexibility and also all the opportunities to screw it up.

Re: Oh my poor business logic

#127

Post by Aqueous »

Tainnor wrote: post #116
Aqueous wrote: post #113

High level architects should focus primarily on creating a system architecture that is designed to incrementally and composably add functionality. This often means adopting some sort of overarching architecture that nudges people towards composable implementations. For write-heavy, highly stateful systems with complex business logic, this means using something like a workflow engine where you can simply declaratively…

> Would also emphasize that while unit testing is often useful for the individual developer working on a piece of code, but as far as ROI, end-to-end integration testing has the most bang for the buck. If you have the full endpoint tested, for instance, from end-to-end, including database writes, your confidence level goes up by an order of magnitude when you have to modify that functionality. If you have to choose b…

I can think of few better investments than to have a reliable suite of end-to-end tests running as part of your merge pipeline even if they're difficult to set up. Sleep quality improves once you have this in place. Your tests don't have to be brittle or flaky. If your tests are brittle it is definitely a good investment to fix whatever's causing the brittleness rather than accept it as a fact of life. Having the tests run against an isolated data and infrastructure environment without additional noise from shared activity is a good first step.

Re: Oh my poor business logic

#128

Post by danbruc »

thom wrote: post #124
danbruc wrote: post #101

Earlier quoted context omitted.

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.

I'm not sure what you're responding to. I'm suggesting you specifically model how things might change to give you a better chance of identifying the right articulation points for your architecture - as in, what if I have to drop one side of this because our assumptions were wrong, but I don't want to lose _everything_? You can't predict the future, but you can built at least _some_ flex into your business and platfor…

See my comment on the sibling comment, I was talking about the trade off between speed and flexibility.

Re: Oh my poor business logic

#129

Post by Tainnor »

Aqueous wrote: post #127
Tainnor wrote: post #116

Earlier quoted context omitted.

> Would also emphasize that while unit testing is often useful for the individual developer working on a piece of code, but as far as ROI, end-to-end integration testing has the most bang for the buck. If you have the full endpoint tested, for instance, from end-to-end, including database writes, your confidence level goes up by an order of magnitude when you have to modify that functionality. If you have to choose b…

I can think of few better investments than to have a reliable suite of end-to-end tests running as part of your merge pipeline even if they're difficult to set up. Sleep quality improves once you have this in place. Your tests don't have to be brittle or flaky. If your tests are brittle it is definitely a good investment to fix whatever's causing the brittleness rather than accept it as a fact of life. Having the tes…

Distributed systems automatically bring challenges that makes it very hard to create reliable test suites. You can reduce the flakey-ness, but I don't think you can ever completely eliminate it.

Beyond that, you haven't addressed the fact that a comprehensive end-to-end test suite in a complex system is really, really slow.

Re: Oh my poor business logic

#130

Post by latchkey »

papercurt wrote: post #52
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…

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

Definitely cultish and yes, I agree... a lot of the engineers were brilliant, but their code was sometimes a bit crazy. I worked with one guy who meta programmed everything in Ruby to the point where even the tests were meta programmed and none of the stack traces made any sense when things failed. The complexity level was just too far over the top for the benefits of the meta programming.

I've also tried to 'change' companies towards Pivotal process. It never really works. People are more than willing to listen, but when it comes down to the practice of things, it just doesn't happen for one reason or another. I think that is why Pivotal Labs works so well... everyone working there is already on the same page and sticks around for many years... and anyone who isn't on page, migrates out relatively quickly.

I think this is also a bit why 'agile' tends to get a lot of hate/fear on HN. You really have to be military and cultish about it from day one, like PL is. Few people are willing to buy into that. Even I was skeptical of it when I first started there and it took me a while to relax into it.

Post reply on HN