Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You Can't Buy Integration

martinfowler.com

Post reply on HN
Print view View original

41–50 of 143 posts

Re: You Can't Buy Integration

#41

Post by nyanpasu64 »

gorgoiler wrote: post #21

Business logic happens line by line between interfaces. Coding may be all ifs and for loops, but when it comes to implementing a new feature, having chosen carefully where to draw the line between, say, your model and your view can be the difference between a 10 line patch and a complete rewrite . If you don’t have a culture of code review then maybe the rewrite will fly, bugs and all, through to production. If howev…

> Java is particularly unforgiving for code where ones thoughts are unclear.

Why is Java bad that way? Overly complex classes? In my experience, C++ is particularly awful, since careless programming can lead to memory corruption, use-after-free, and nonlocal malfunctions and crashes.

Re: You Can't Buy Integration

#42

Post by dsanchez97 »

I agree with most the tradeoffs that were brought up with "low code" integrations tools, but I feel like none of the tradeoffs of using a general purpose program language were discussed. My viewpoint is that most organizations reach for these solutions because they provide highly available runtimes that people can quickly access.

If I am at an organization and not directly on a software development team and want to do a simple data transformation between two systems, how would I go about getting an environment to run my process? Even if I know how to write it using a general purpose language there are probably too many steps to go through to get a server environment to run my code on. With a low code solution, I can get my simple process running and automated much easier.

A little while ago there was an article about the python environment run at big banks that allow banking analysts to easily use python to solve their day to day problems. The banking python system was built to allow these people to quickly write python without much organizational overhead and therefore saw wide spread adoption among non traditional software developers.

I have been thinking about this space because I am trying to build a platform on top of serverless (FaaS) platforms that would make it easy for companies to empower workers to use general purpose programming languages to solve their business problems.

Re: You Can't Buy Integration

#43

Post by travisgriggs »

qxmat wrote: post #28
keyle wrote: post #7

Earlier quoted context omitted.

I got bounced off a front-end job once, for not being good enough at React. Mind you I've been building SPA's since they weren't "a thing" and today I mostly use Vue. But for that role, they didn't like my lack of .env variables in the front-end (such as for things that end up in the HTML), after a 3 hours coding test, and a couple of minor React-y tid bits they couldn't even clarify. Basically, not "idiomatic". Mean…

I've worked with people of varying skill-levels but personally gravitate towards those who can code idiomatically. For me it's important I write idiomatic code and follow the language/framework/api guidelines to the letter so I don't become a maintenance burden to my team. In the fast-paced world of frontend dev, the last thing I want to do is revisit "complete" work, be it a lack of env parametrisation or something…

Which idioms? This week’s? Or last week’s? If I’m at guru level and am capable of evolving to whatever next week’s idiom is, can we code together then?

I agree with you in general. But I do find that this litmus test sets up a moving target in some of today’s more trendy/culty language ecosystems.

Re: You Can't Buy Integration

#44

Post by VHRanger »

nyanpasu64 wrote: post #41
gorgoiler wrote: post #21

Business logic happens line by line between interfaces. Coding may be all ifs and for loops, but when it comes to implementing a new feature, having chosen carefully where to draw the line between, say, your model and your view can be the difference between a 10 line patch and a complete rewrite . If you don’t have a culture of code review then maybe the rewrite will fly, bugs and all, through to production. If howev…

> Java is particularly unforgiving for code where ones thoughts are unclear. Why is Java bad that way? Overly complex classes? In my experience, C++ is particularly awful, since careless programming can lead to memory corruption, use-after-free, and nonlocal malfunctions and crashes.

At this point the issues with Java are cultural, but they used to be evolutions of constraints of the rigid "everything must be a class" model.

If nothing in the architecture can just be a free-floating procedure, not even a pure function, the system architecture will evolve around this

Re: You Can't Buy Integration

#45

Post by barnyfried »

keyle wrote: post #7
jefflombardjr wrote: post #3

Really great read. Long but worth it. This is a good critique of low-code/no-code in general. The root problem I see of "Unfortunately, when we frame the problem space that way, we have allowed our tools to think for us." is that in reality there are just not enough qualified software engineers out there.

I got bounced off a front-end job once, for not being good enough at React. Mind you I've been building SPA's since they weren't "a thing" and today I mostly use Vue. But for that role, they didn't like my lack of .env variables in the front-end (such as for things that end up in the HTML), after a 3 hours coding test, and a couple of minor React-y tid bits they couldn't even clarify. Basically, not "idiomatic". Mean…

Keyle,

I would like to hire you on my next web aka "phony react mobile" project. And Im not kidding if I had your deets I would totally hire you. This is sort of the exact problem but we cant talk about the exact problem.

Re: You Can't Buy Integration

#46

Post by hoten »

dsanchez97 wrote: post #42

I agree with most the tradeoffs that were brought up with "low code" integrations tools, but I feel like none of the tradeoffs of using a general purpose program language were discussed. My viewpoint is that most organizations reach for these solutions because they provide highly available runtimes that people can quickly access. If I am at an organization and not directly on a software development team and want to d…

The referenced article on Python in banking: https://news.ycombinator.com/item?id=29104047&p=2

Re: You Can't Buy Integration

#47

Post by kayodelycaon »

NikolaNovak wrote: post #31
hinkley wrote: post #15

Earlier quoted context omitted.

I’ve hear the way to succeed with SAP is to reorganize your business to match either the default world view or some other cookie cutter variant. Essentially using it no code style. Otherwise you’re exerting yourself doing “normal” things. That’s not sustainable.

All ERPs are fundamentally like that. At the end of the day you are purchasing a COTS product specifically to gain efficiency of industry best practices already coded for you. If you take a COTS product and then try to rewrite it to fit your "unique" business processes, we'll, that's why half of them fail. Implementation of erp is incorrectly and disastrously viewed as an IT project. It is first and foremost a busine…

This is why my company has custom applications that talk to the ERP for certain departments. Inventory control in the ERP isn’t going to work with reality. The data modeling is good enough but the interface is not.

Rather than train everyone we hire to use horrifically bad and expensive barcode readers, we purchased cheap smart phones, put them in cases, and locked them down to run an app that uses the camera to scan barcodes. Drop a phone? It’s encased in rubber. Run it over with a forklift? Toss them another one from the box and then figure out why this only happens on Tuesday afternoons.

We already need a dev team for other reasons. Adding another decent programmer to create and support internal apps isn’t that expensive in the long run. Plenty of good devs like me who are happy to work remote from the Midwest at less than FAANG rates. :)

Re: You Can't Buy Integration

#48

Post by barnyfried »

Ok so here's the deal, although this is sort of well written-ish.

There is absolutely no surprise waiting for us in COTS, phony 4GLs that purport to "solve a problem". I mean really? The fact that people still huck these tools means the software business might not be dead. Now if you work for a company that buys these things, I hope your not in tech. Because these fool things which are "container engines for consultants", will cost you a ton of money.

Maybe you prefer it that way?, its your money. The technical argument which sort of tried to make some point relative to event driven architecture was pretty obviously weak. Whether or not I personally agree with that architecture, I think that there could be arguments made there.

But we have MUCH bigger problems in tech. Some of them we cant talk about openly. Like labor sourcing and scrum. So we may have people problems folks.

Let tool salesmen do their jobs and tend your own field and your own flock.

Re: You Can't Buy Integration

#49

Post by lmm »

dsanchez97 wrote: post #42

I agree with most the tradeoffs that were brought up with "low code" integrations tools, but I feel like none of the tradeoffs of using a general purpose program language were discussed. My viewpoint is that most organizations reach for these solutions because they provide highly available runtimes that people can quickly access. If I am at an organization and not directly on a software development team and want to d…

It's the configuration complexity clock all over again. Code errors cause outages, then we impose a bunch of process and restrictions on code deployment, then we make our code configurable so that business users can easily change the behaviour, then configuration errors cause outages.

Re: You Can't Buy Integration

#50

Post by mr_toad »

throwaway984393 wrote: post #24

"Integration software products ... are not products that directly solve a business problem. ... They are programming languages, bundled with a toolchain and a runtime to support the compilation process." By this definition, Excel is a form of integration tool. A spreadsheet doesn't "directly solve a business problem". It's basically just a piece of paper with lines on it, along with some "programming formulas". A ham…

> By this definition, Excel is a form of integration tool.

If you’re unlucky it’s your only integration tool. When there are no APIs, when you can’t get approval to use a tool or language, when the DBAs won’t return your calls; then export to Excel is the only integration tool you’ve got.

Post reply on HN