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

91–100 of 143 posts

Re: You Can't Buy Integration

#91

Post by theshrike79 »

hinkley wrote: post #15
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’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.

Yep, this is the SAP way.

Either you match your business to the SAP Way or your multi-million SAP integration project will fail. There are no other options.

You can theoretically prolong the inevitable by modifying SAP to fit your business model, but then it'll just break and fail during the next update.

Re: You Can't Buy Integration

#92

Post by bullen »

gorgoiler wrote: post #71
nyanpasu64 wrote: post #41

Earlier quoted context omitted.

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

Java involves lots of ceremony, lots of types, and a formal structure that lent itself to being a very verbose language. That has never sat well with any kind of source control where you are expressing your ideas with line oriented patches.

I think you are confusing Java and the tools built on top of Java.

I only code with JavaSE and only use 2 external dependencies (original json and dns4j, both minimalist and written by one man each), that said Java probably has the leanest API that has ever existed and potentially that will ever exist.

Re: You Can't Buy Integration

#93

Post by gherkinnn »

gitfan86 wrote: post #25
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 have been in a similar boat. I was spending a bunch of time avoiding extra API calls and extra renders in React and the team I was working with didn't seem to understand that there were potential performance issues around that. They said "just use memo" On the other hand I think it is a natural progression. 30 years ago experienced engineers would look at young people who didn't know how to fix a PCB or read byteco…

I can’t build a fire in the rain, nor can I skin and prepare an animal. But I can buy a slab of beef and chuck it in a pan.

If we’d all be stuck with the very basics, we’d be nowhere. This is why abstraction and specialisation are important.

Re: You Can't Buy Integration

#94

Post by skydhash »

zmmmmm wrote: post #70
q-big wrote: post #60

Earlier quoted context omitted.

> You Can't Buy Someone Else Caring about Your Problems This is easy: when you give people a huge amount of money to care about your problem, they will. This, of course, does not imply that they will be able to solve them. > You Can't Buy Understanding of Your Problems This is less easy, but also possible: spend sufficient money so that highly intelligent people (think graduated mathematicians or theoretical physicis…

> This is easy: when you give people a huge amount of money to care about your problem, they will You can pay them enough to care as far as they get their last payment. How do you get them to care what happens after that?

Shared ownership of the business?

Re: You Can't Buy Integration

#95

Post by hef19898 »

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 have it seen time and again. Organizations and leadership being faced with a problem and jumping directly to tool / software selection and implementation before really having understood the problem itself, the processes and requirements. After selection, directly to implementation. Because, you know, we a re agile and working in sprints. So we can sort out architecture and interfaces as we go. End result, tools force you into the use not understood processes that have nothing to do with your business requirements whatsoever, an architecture that is cobbled together and users that don't understand neither.

Even better if the tools are selected based on previous experience alone.

Re: You Can't Buy Integration

#97

Post by sokoloff »

trabant00 wrote: post #81

There's a lot of things you can't buy in IT. There's a lot of things you don't need to either because they are free. For all this you must find people who are passionate and have interests aligned to your own. This is how I aim to hold the interviews I conduct for infrastructure engineers. The most important question I ask is "Why do you want to work in this position?". 10 years ago I used to care mostly about candid…

I’ll happily write working computer programs for free and do it in my spare time and with my kids.

What companies are paying me for is to focus on and solve the company’s specific problems.

Re: You Can't Buy Integration

#98

Post by pjmlp »

gitfan86 wrote: post #37
debaserab2 wrote: post #27

Earlier quoted context omitted.

It does make you wonder what is going to get missed though, doesn't it? Each generation gets to work on a level of abstraction higher than the one before it. I think about that often when I think about all the things I don't understand about hardware and EE.

I did computer engineering in school 20 years ago, and have always enjoyed understanding technology. So I know what is happening from the gate in the cpu all the way up to the pixel in the monitor. The downside is that I'm spread pretty thin. I can't pass leetcode exams in the 30 minutes of allotted time, ops people can't understand why I don't use containers, and my knowledge is probably useless in making a modern C…

Having been coding for 35+ years, I feel you.

Re: You Can't Buy Integration

#99

Post by pjmlp »

Stranger43 wrote: post #78
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…

How do you get time/instances on an no code platform? This problem was solved in 80ies on most timeshare platforms(read unix) where you would simply let users access an general purpose environment on a shared server and run processes in the background or kick up batch job using some kind of scheduler(crontab). The old unix "shell account" should really be the benchmark for FaaS to beat and so far i dont think anyone…

On SaaS providers where Cloud Shell is the new telnet and the browser the X Windows replacement.

Re: You Can't Buy Integration

#100

Post by pjmlp »

lloydatkinson wrote: post #36
sam_lowry_ wrote: post #35

In Microsoft BizTalk one could make transformation rules not by drag-and-dropping but by coding in some weird XSLT dialect. It was a joy to use compared to the usual three-pane screen.

What actually is BizTalk? I'm a .NET dev pretty involved in the Microsoft stack and never once have I seen it in use or worked anywhere that uses it.

For how long?

BizTalk heyday was during the Visual Studio.NET early days when SOAP was going to take the up the world of distributed computing as main replacement for CORBA/DCOM.

Post reply on HN