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

51–60 of 143 posts

Re: You Can't Buy Integration

#51

Post by htrp »

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.

That's almost every ERP system....

You could customize it to match your business, but 90% of the time that would cost more than reorganizing your business.

Re: You Can't Buy Integration

#52

Post by malermeister »

csours wrote: post #4

You Can't Buy Understanding of Your Problems You Can't Buy Someone Else Caring about Your Problems It seems like you can hire experts to understand and consultants to care about your problems, but someone has to bring the intent and to close the loop.

You can hire experts to pretend they care and do whatever's the most convenient for them and since you don't understand, you'll never know the difference.

Re: You Can't Buy Integration

#53

Post by keyle »

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…

This resonates with me.

I'm actually thinking that at some point, no one will be building custom software. Everything will be available off the shelf, as some product, running on some cloud within a few clicks.

So "custom software" developers are a dying breed.

For example, when Jira is down, a Jira "specialist" will tinker and bring it back and look like some guru walking down the mountain of knowledge. Arguably, this person probably wouldn't know anything about SIMD. Yet the SIMD guy is looking for a job, no one cares about that guy. But the "salesforce developers" and "Jira specialist" are permanently employed at very high wages.

Re: You Can't Buy Integration

#54

Post by nicoburns »

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.

I think classes in general. They are often a poor abstraction, and that leads to hard to refactor code.

Re: You Can't Buy Integration

#55

Post by nicoburns »

travisgriggs wrote: post #43
qxmat wrote: post #28

Earlier quoted context omitted.

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.

I think it depends: not using specifically env variables for configuration should let be a big deal. But hard coding values rather than using some sort of configuration file is bad practice and could cause issues on a team.

Re: You Can't Buy Integration

#56

Post by nwhatt »

It's not really clear if this advice is for within the enterprise (a company that maintains so many systems they spend millions to integrate them) or at the edge (a company that needs to integrate with multiple third parties). I can see the argument for the intra-enterprise work being valuable, but at the edge I'm less convinced.

Re: You Can't Buy Integration

#57

Post by fitzoh »

Two things missing from the Step Functions portion of the article:

* Step Functions module in the AWS CDK: https://docs.aws.amazon.com/cdk/api/latest/docs/aws-stepfunc...

* Step Functions Data Science SDK (python): https://aws-step-functions-data-science-sdk.readthedocs.io/e...

There is first class support for defining Step Functions using real programming languages (although it does compile down to the states language dls before deployment)

Re: You Can't Buy Integration

#58

Post by chasil »

nwhatt wrote: post #56

It's not really clear if this advice is for within the enterprise (a company that maintains so many systems they spend millions to integrate them) or at the edge (a company that needs to integrate with multiple third parties). I can see the argument for the intra-enterprise work being valuable, but at the edge I'm less convinced.

I arrived in my position in the late 90's, greeted by HP-UX, VAX VMS, and Unisys OS2200.

All of this was tied by our homegrown queue software.

Some years later, I was tasked with migrating HP-UX to Linux, in stages, and I was lucky enough to have found all the queueing source code, and I rebuilt it, imperfectly, on Linux. We hired back our past workers, including the original author, who made perfect my original port.

As the years have passed, I continued to improve this code, compiling with directives from "hardening-check" after bug hunts.

It has tied me to my role, but I suppose that I am happy here.

Re: You Can't Buy Integration

#59

Post by bbyars »

nwhatt wrote: post #56

It's not really clear if this advice is for within the enterprise (a company that maintains so many systems they spend millions to integrate them) or at the edge (a company that needs to integrate with multiple third parties). I can see the argument for the intra-enterprise work being valuable, but at the edge I'm less convinced.

Good feedback. Most of the article is about integration inside an enterprise, although in the next installment I do talk about integration between organizations (hint: there are scenarios where I think low-code tools make sense there).

Re: You Can't Buy Integration

#60

Post by q-big »

csours wrote: post #4

You Can't Buy Understanding of Your Problems You Can't Buy Someone Else Caring about Your Problems It seems like you can hire experts to understand and consultants to care about your problems, but someone has to bring the intent and to close the loop.

> 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 physicists) will organize their life around understanding your problem. Because they are highly smart, they will very likely understand after some amount of time (hey, understanding highly complicated stuff by reading papers is what you do in graduate school).

---

So the problem rather is: you are not willing to spend that much money or are far too impatient on people (i.e. you want a "fast solution" instead of someone who really deeply wants to understand everything from ground up as you do when in math research).

Post reply on HN