Comment by sailfast | Hacker News Reader

Comment by sailfast | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com