Hacker News Reader

Comment by michaelt | Hacker News Reader

Let's not exaggerate here, the software industry managed to deliver software for on-premise use for several decades.

They used things like standardized packaging mechanisms, matrix testing across supported profiles, dedicated staging environments, and sensible logging schemes. These are expensive and time-consuming! Product velocity is greatly increased when less time is spent on such engineering cruft.

AND a several orders of magnitude larger investment in tech writers, and manual "How can my customer break this software" testing.

When I worked in shrink-wrapped software back in dark ages the documentation writing team and a very extensive manual QA department where each the same size as the development department. Think people trying for DAYS to find out why out of 100s of thousands of active users, a few dozen reported being able to launch 2 instances of the main window when that should not be allowed. (Fix: Race condition in the "double click" handling code with a window of a few milliseconds)

> standardized packaging mechanisms, matrix testing across supported profiles

While this is somewhat true, it's not unreasonable to keep the matrix very small to start with and gradually expand it. People think that matrix testing is some insurmountable task when it mainly comes down to some reasonable, thoughtful engineering. If for some reason you've got some part of the matrix that's particularly expensive (looking at you AIX) then charge a heavy premium for that platform.

> dedicated staging environments

Even if you're a SaaS company you should have dedicated staging environments. Without this you're using your customers as QA, and that's just rude.

> sensible logging schemes

Please have sensible logging schemes. Your on-call/ops folks deserve to be happy too.

Having lived on both sides of the on-prem / SaaS flow, the things that make an on-prem offering successful also make the SaaS offering easier to develop, maintain, and troubleshoot. On-prem can be more expensive but it also means bigger deals, more predictable income, and higher margins. Not every company can fully adopt the mechanisms to generate an on-prem offering but the purported costs of an on-prem offering frequently come down to "ship higher quality software" rather than "shipping somewhat sketchy code at a breakneck pace."

> Product velocity is greatly increased when less time is spent on such engineering cruft.

This attitude is why I get paged. Perhaps we shouldn’t be encouraging lightning-fast growth above all else.

This attitude is why the IT field is never going away. Businesses need adults and professionals ensuring reliable infrastructure, not "product velocity".

This is very circular -- yes, that's true.. and because it was so difficult everyone, vendor and customer alike, moved towards SaaS hosted offerings.

There has to be a name for this argument-type: A leads to B, and those who seem to know only B start arguing for A because they don't remember why A lead to B in the first place. I see this all over the place.

I don't know that the shift was about difficulty, at least not primarily. As best I can tell it's more about profit, and companies usually move to SaaS because it makes them more money and the other pluses and minuses are less important to them.

I know as a consumer I'm much more reluctant to buy a new subscription product than I am to make a single purchase, but the options get less and less every year.

This is exactly it. On-prem deals were generally large perpetual license fees based on some quantity of software installed, and then a % of that as an annual "maintenance" fee which would provide access to support and software updates.

The problem was that the maintenance revenue was valued at a much higher multiple by investors than their Perpetual Licensing revenue because it was recurring. Cue the thought... "What if the whole thing was recurring?"..."Hmm how could we justify that?"..."We make it a SERVICE that WE host!"... and then here we are now where if you want to actually own software, chances are you're out of luck.

It can also be how difficult it is to support on-premise software installations especially when customers use leverage to keep from updating to recent releases that had bug and security fixes, etc…

I ran a SaaS and PaaS for fintechs and we had annual events where we had to hard negotiate with customers who didn’t want to incur the employee training burden for upgrading to newer releases with new features etc. Instead of accepting the rolling releases they would do one or two updates/year and we would stand up monolithic support programs to accommodate them. Moving away from this customer model was about headaches and release/support debt.

There are a lot of challenges with complex on-perm solutions that hosting-for-customers can alleviate. Staffing for every customer hosting variation gets unduly complicated — and impossible — very quickly.

I think it's also about changing expectations and environment. Big customers expect timely updates for the purposes of security, keeping third party integrations working, and bugfixing. They also expect high uptime and prompt outage mitigation. That's really hard to square with on-premise offerings.

Don't get me wrong, it's also hard, but providing on-premise software is less difficult than it used to be in absolute terms. The main things that changed are SaaS driving expectations up, and needing to upgrade faster.

>> because it was so difficult everyone, vendor and customer alike, moved towards SaaS hosted offerings

I actually remember why one company I worked for moved from on-premise to SaaS. They told us that the market valued recurring software revenue at a higher multiple than it did one-time software revenue.

On-prem was a large one-time sale and a small recurring support contract. SaaS was almost all recurring revenue.

On the customer side, it is capital expenses vs. operating expenses.

And some companies continue to do so! It's not a lost technology. But the way it typically works is that big contracts come with a ops engineer or two to live with the customer and help them set it up.

At some companies, this is clearly demarcated from the SWE role - at others, stereotypically the "IBM mainframes, SAP and Oracle DBs" category the OP mentions, they kinda shade into each other. Which is, of course, why those technologies have such negative reputations. (There's also the Palantir route, where you have a clear demarcation but lie about it to new grads who don't fully understand the conflict between "forward deployed" and "software engineer".)

Reply on news.ycombinator.com