3 ms·

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

freeone3000 3y ago
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.
- sgarland 3y ago
  > 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.
  - ocdtrekkie 3y ago
    This attitude is why the IT field is never going away. Businesses need adults and professionals ensuring reliable infrastructure, not "product velocity".
- amichal 3y ago
  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)
- coldbrewed 3y ago
  > 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."
browningstreet 3y ago
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.
- rurp 3y ago
  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.
  - nlavezzo 3y ago
    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.
    - browningstreet 3y ago
      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.
SpicyLemonZest 3y ago
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".)

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.

sgarland 3y ago
> 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.
- ocdtrekkie 3y ago
  This attitude is why the IT field is never going away. Businesses need adults and professionals ensuring reliable infrastructure, not "product velocity".
amichal 3y ago
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)
coldbrewed 3y ago
> 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."

browningstreet 3y ago

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.

rurp 3y ago
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.
- nlavezzo 3y ago
  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.
  - browningstreet 3y ago
    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.

SpicyLemonZest 3y ago

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".)