Live data from Hacker News

You Can't Buy Integration

martinfowler.com

31–40 of 143 posts

Re: You Can't Buy Integration

#31
post #15

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.

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 business transformation project. A company should be self-aware to say "HR|Accounting|whatever is NOT our core business or competitive advantage; it's not what we are great at. It's not a thing we should be unique in. It's a cost centre and we need to standardize and minimize that cost with help of people and software that were successful with many other companies".

(Source: I've been implementing Peoplesoft, a competing erp,for 20 years for dozens of companies, as a technical resource eventually wise enough to be aware it's fundamentally not a technical endeavour :-)

Re: You Can't Buy Integration

#32
post #15

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.

This outlook is actually endemic in the ERP implementation space.

The part you're not going to like hearing is that, due to laws/regulations, that "default world view" may be the best way to approach that problem for that given module/area (e.g. how to structure benefits or compensation). "Creativity" in the ERP space is costly.

Also reducing your variation to something that's configurable as opposed to custom codebase means you don't have to do extensive testing whenever a patch or upgrade to the ERP software comes out.

Re: You Can't Buy Integration

#33
post #7

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…

> Meanwhile, none of them could tell me how React actually works, beyond throwing jargon vomit. They couldn't write a web application without React. The recruiter, which we had to go through, basically had no empathy and saw me as a failed resume. I felt pretty helpless, even though I've said many times to both parties that I wasn't a "React developer".

But they don't make money by knowing "how React works". They make money by "writing good-enough React code that pushes features to production". I think get you, and in some sense I feel identified with you, it's just that the industry has shifted from "let's care about our craft" to "let's write good-enough code to make more money"... makes me sad, but hey, it's business I suppose.

I couldn't care less that a candidate knows what "React hooks" are (that's probably gonna be outdated in 1 or 2 years). I care if they know how to write modular code. Management doesn't have the same opinion, though: employees usually work for 1 to 2 years at the same company... so knowing what "React hooks" are now, matters for them.

Re: You Can't Buy Integration

#34

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

> "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 hammer would be an integration tool if it were digital.

You're misreading that quote. The direction is actually important in conveying meaning, it's like trying to misread "Every ancient poet known as Homer was a man" as "all men are ancient poets known as Homer".

Re: You Can't Buy Integration

#36

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.

Re: You Can't Buy Integration

#37

Earlier quoted context omitted.

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…

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

Re: You Can't Buy Integration

#38

Earlier quoted context omitted.

Hah, I posit that there is a _very_ low possibility of buying someone to care about your problems.

Everyone has a price.

I posit that paying money only buys the appearance of caring, not the actual caring. That is the reason celebrities get (got? Not up to date) doctors who prescribed addictive drugs, because they just gave the client what they wanted, not what they needed. You really want someone who speaks truth to power, not just pleasing nonsense. And the power must be able to discern the two.

Re: You Can't Buy Integration

#39

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…

The line “coding is just if statements” really annoys me. I used to think this earlier in my career. It’s technically true but it means that you haven’t really grasped what makes programming hard. The real challenge of programming is how you organize a million if statements in a way that the system can be understood and evolved predictably and cheaply over time. And any tool that takes away the control of how you org…

Coding is just if statements, more or less. Programming and coding are different words with different meanings, though. What is the reason to conflate them?

Re: You Can't Buy Integration

#40

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.

Did you try wikipedia[0] or microsoft[1]? It's been around 20 years, but it's been fading away the last 5

[0]: https://en.wikipedia.org/wiki/Microsoft_BizTalk_Server [1]: https://partner.microsoft.com/en-us/solutions/microsoft-bizt...

Post reply on HN