Hacker News Reader

Comment by JMTQp8lwXL | Hacker News Reader

This sounds like it was written by someone who hasn't worked with ERP systems, to give an example of where software will never eat software. "Can we make A work with B?" -- a lot of businesses tie together Salesforce + 8 other systems, and that's how their business ticks. And a whole cottage industry forms around it: consultancies, etc. I need to see a clear non hand-waving explanation for how all of that complexity melts away.

The industry has already tried commoditizing by off-shoring. What we learned was high-performance teams require psychological safety and trust. The human factors involved in creating software are why engineers are not plug-n-play. Because that reduction of the problem doesn't describe how the software is actually made: product solicits customer interviews/data to recommend new features, architects brainstorm a high-level solution, and the IC engineers implement the vision. Human factors, through and through.

View on HN

> This sounds like it was written by someone who hasn't worked with...

Every broad article I've seen like this speaks about 'software' as if it is a monolithic career path. The lives of web programmers, embedded engineers, AI researchers, ERP programmers(etc, etc) are all quite different. Most of the articles I've see on programming/software engineering don't capture the things I've experienced over my 23 years as a programmer.

And then there's the "invisible programmers", the ones who might cross-train as IT technicians, who write internal-only software on an as-needed basis. Need a report? Need a webapp so people can work with a business process database? Need to integrate a CRM into Jira by pulling information out of its backend database nobody has a schema for? Not the kind of stuff they teach you in school, bucko, but someone has to do it.

To me this is a super underrepresented group if you can call it that. Tons and tons of mid market companies have more of these programmers than traditional CS grads.

When is the last time anyone considered an Application Analyst a developer? On a small scale, they often do that.

I believe they were referred to as catfish programmers here a while ago. We say hello.

https://news.ycombinator.com/item?id=14564455

100% agreed that people are performing higher level functions today that software can't perform.

However, I think your first point about multi-system interconnectivity is ripe for change.

It's been the case that the literal act of running a business has been humans serving as copy-paste bots between systems, both internal and external. Come to think of it, from a purely software point of view, businesses look a lot like giant, multi-system ETL machines, except that the individual steps in the pipeline (Salesforce, SAP, Netsuite, etc.) don't talk to each other. This is even worse when it comes to interactions with other businesses (customers/vendors/partners) - everyone has different systems and none of them talk to each other.

So we fall back to the lowest common denominator - Email + attachments (XLSX, PDF), CSV over FTP etc.

The fundamental problem is not very different from the challenge of human language translations. Getting SAP to talk to Salesforce is a similar class of problem as enabling an English speaker to talk to a Hindi or Mandarin speaker. If the latter is a solvable (solved?) problem, I don't see why software talking to software is that different. There are of course domain specific challenges, like the fact that both systems being translated between require 100% translation accuracy.

We are working on solving this at https://42layers.io. It's early days for us, but this is exactly the problem we are solving.

The way I see it, the fundamental problem is that the producers of these systems don't want them to talk freely to each other. Every vendor wants to control the conversation (and when you see someone calling their product a "platform", you know they want to control all the conversations in a given sector). E-mail is the lowest common denominator that works, because it happened in the age where computer technology was developed to coordinate, not to compete and control.

Conversations between systems is an easy problem, in the same way translating English to Mandarin is easy if both people are also fluent in Hindi - they can round-trip through the shared language. Systems designers can also negotiate a common protocol. It doesn't have to be automated, it can work just as well with some programmers continuously keeping the protocols up to date. The problem is, there's a strong business imperative to not do any of that.

Super underrated comment. What's even worse is that, internally, large companies have small groups that create bespoke solutions and then try to sell those solutions to the rest of the company. I've seen so many "final frameworks" that are going to solve all of the problems that are then sold to all of the other groups, who try to move their stuff onto that framework, but wait now Team X has another framework and oh man which one should we follow? It's just a new version of the fundamental problem of getting diverse human groups with diverse needs to standardize on some solution, with all of the economic incentives you described mixed in. Frankly I think the people who got this problem closest to right were the American Founding Fathers. This is fundamentally a political problem. The best technical solution I've seen proposed is in the talk "Architecture Without an End State," where the speaker talks about how to make smart decisions in a decentralized environment.

Brilliant!

> English to Mandarin is easy if both people are also fluent in Hindi

This is so true. In one of my tasks as a consultant at a law firm, this is literally what happened when working on a plaintiff side case.

A partner spoke Mandarin, Japanese and Hindi while I spoke English, Hindi. We were called upon by translators a lot to proof eDiscovery case files.

re: 42layers - a quick look at your site shows a "contact us" - so, contacting you this way - how are you solving this hindi/mandarin problem? :-)

I'll try and answer that to an extent here :)

Lots of companies trying to build low-code solutions to help business people glue systems together. However, for pretty much all of these solutions, while the end user isn't writing code, they are forced to think like a programmer - if/else, loops etc.

We are taking a very different approach.

We've built a transform engine that can be trained on transforming data from a source structure to a destination structure using a few (10s) of examples of source and destination. We can do this transformation without falling into the trap of figuring out acceptable confidence levels - a trap that most ML systems fall into, and thus have a hard time with enterprise usage.

We couple that with dynamic, configurable integration infrastructure ("connectors" in old school enterprise speak) that can send+receive data to/from lots of systems over many protocols and serialization systems.

End result is that end users can connect systems together with a few clicks and by providing a few lines fo training examples, not unlike what a business person would give a dev and say "extract a CSV from SAP and put it in that FTP folder. the CSV needs to look like this file"

>>> forced to think like a programmer

That is the failure of every ORM and visual programming tool I have seen.

(But i happen to think that being forced to think like a programmer is good - on the order of being forced to think like a literate person would have been a few hundred years ago)

But interesting if you can do it.

In your specific SalesForce scenario they built SalesForce to stop people from coding CRM systems, and then people continue to make money building connected abstractions / Apps on top of other systems that are SalesForce compatible so you get an app ecosystem that abstracts away all of these integrations. The result is less code.

I agree that there is a lot of complexity specifically for "mission critical" or "last mile" systems that will not be addressed by the mainstream abstractions for many organizations, but I don't think SalesForce is necessarily the best example. I see the author's hypothesis freeing up time to do a lot more things within organizations that are otherwise on the back burner because you can't get to that feature set, and/or pivoting to solve either a) complex problems that are not yet solved or b) specializing on a layer that is now "platform". Somebody builds AWS, and Azure, and GCP. Somebody has to create, build and maintain the next platform / abstraction too.

I think your falacy is in the "less code" assumption when you say "The result is less code". I'd argue that empirially we've seen this to be false. The result isn't less code, at least in a global sense, its more productivity, more features, more customization, and more specificity at a cost of less code/feature. Software has really interesting economics where as the cost/feature decreases by a factor, say 1x, then the set of features that can be profitably worked on expands by like 10x, so paradoxically, as cost/feature decreases, it makes sense to hire more engineers and expand R&D budgets.

The Jevons effect is not especially peculiar to software.

I think ultimately, the question is whether this trend will result in "fewer programmers needed", which is the most important by-product of "less code" in the author's thesis.

Did we slash R&D budgets once we standardized on the X_86 instruction set thus needing less compiler devs? Did we slash R&D budgets when we moved from on prem to cloud hosting? We have seen this happen many times before, we know the economics. Decreasing cost/feature is synonymous with increasing productivity. We know that a 1x increase in productivity results in a very large increase in the numbers of features that become feasible.

There isn’t some fixed factor here that causes it all to collapse. Productivity increases are plowed into growing the market 10x and building the business, not reducing eng budgets. At some point in the future this will slow down, but that is so far from happening, like many decades from now, maybe never in a non theoretical sense.

Yup - this is a much better way of describing the intent of my words. Thanks.

> The result is less code.

No, it's more code with a greater value:code ratio. It's lower code for the same delivered value, but no one stops at the same delivered value that they'd have without whatever tipped that ratio, because the incremental value for the next unit of code is higher.

Increasing the value delivered per unit of code increases the volume of code purchased.

Related, if maybe not quite the same thing: https://en.m.wikipedia.org/wiki/Jevons_paradox

Yes this is a much more elegant way of putting it. Thanks.

>> The result is less code.

Maybe, but that code tends to be extremely bad quality, because it is always written by "consultants" who know just enough programming to be dangerous and do the bare minimum to get the integration to work, without any concern for or the ability to follow software engineering best practices. And that introduces its own costs.

I think no-code is different than off-shoring. Wherewith offshoring you needed domain expert, some kind software architect which maps features and off-shored team, with you no-code you need usually only domain expert.

>This sounds like it was written by someone who hasn't worked with ERP systems, to give an example of where software will never eat software.

Software has already been eating software. Imaging building something like Salesforce or an ERP system using only Assembly. Just as programming languages like Java became an abstraction level over Assembly and simplified development of complex systems, something else will emerge (or is already emerging) as a higher level abstraction and will enable creating even more complex systems.

>The industry has already tried commoditizing by off-shoring.

Offshoring doesn't create a new abstraction level.

Zoom seems to do alright.

Reply on news.ycombinator.com