1. 1
  1.  

  2. 5

    Imagine if you had to support your software nine years from now. I’m used to it since we develop embedded c++ code for coffee machines that have an average lifespan of 10 years, refurbished even longer, but your run of the mill crud webapp? That has to be rewritten 10 times in the hip new framework of this year to achieve that span.

    1. 1

      You’re not competing against 19 other coffee machines. Someone doesn’t place a new hip matcha lattè machine next to yours that you then have to retrofit to also provide a competing feature set (or risk losing customers).

      Coffee machines have simple requirements that are quite stable; it’s not too hard to write software for them that can last essentially forever: once it works, it works. This is very different from the “webapp” world where requirements, user expectations, and so forth constantly change.

      1. 7

        To summarize, our case is much more like you described than you think. Ever changing requirements, New features, New hardware, etc.

        Speaking on personal title, the machines we make are large machines for cafes and companies, with a touch screen and a variety of swappable components. They are running Linux with our coffee application, which evolved over 20 years, from.an eeprom to a rtos on a microcontroller to Linux on arm nowadays. The same software runs all our machines, a config file makes a machine special.

        You’d be surprised how many competitors we have. A coffee machine is basically just a bunch of motors and valves as a software point of view, but our config file (where you define the consumptions) is a turing complete beast of binary xml going back 20 years.

        But via that config file customers can program that new hip latte on their machine themselves, change how long the pumps run, which valves open when, how much water, pressure, how many grams of beans, you name it and it’s configurable.

        What does change are feature requests from customers, our iot connectivity, recently we did a touchless option. (Scan qr and get a webpage with the same screen as the machine), For covid proof coffee. Which as interesting, how do you scale that to thousands of machines with a limit of 7MB /month in data? We ended up using mqtt.

        But two of our competitors already launched the same idea (qr touchless) a month before we finished.

        As for other changes, we also make the hardware (brewing hardware), grinders, canisters for making coffee, which require more software control than it used to be (now we dynamically monitor and respond to flow and pressure changes instead of just driving a motor and pump, make sure we have that 9 bar for the entire consumption. Pump a bit harder, restrict flow, etc, all while making one drunk.).

        You could choose not to update your machine regularly, but then you’d miss out on bug fixes and new features. (A recent update shaved off 3 seconds of a brew, which, when doing 300+ consumptions a day is quite big). We make sure the machines work offline first and you get all the tools to program them yourself, so ten years from now you don’t need us, we might be out off business. Don’t want to create so much e waste).

        1. 1

          Thanks for the context; it looks like I underestimated the complexity 😅

          Still, as someone involved in the “webapp” side of the world for 15-odd years, it seems to me that the world of the the web has changed much more in the same time period. 15 years ago there were no mobile platforms to take in to account, and the entire way the webapp worked was a full page refresh instead of more “desktop-like” applications.[1] These are really big paradigm shifts; adding new features and such on your coffee firmware sounds like that’s just modifying/improving existing code (or writing a new bunch of code), rather than a paradigm shift in how you build things.

          I too think there’s a bit too much of a “framework of the year” mentality at times, but I suppose that’s because this is all so comparatively new that we’re all figuring out what the best way to build these applications is, and this is kind of part of that. I’ve sometimes compared it to all the weird and alien lifeforms during the Cambrian explosion when life and evolution was kind of figuring out what worked and what didn’t.


          [1]: As an aside, before we all ridicule the webapp complexity: I can now do my taxes in a webapp, on any platform, which works quite well. 15 years ago I had to download some crappy Windows tool which put random files in my C:/ drive.

      2. 1

        I don’t think that’s a good comparison. When I buy a coffee machine I expect it to work. The only reason I’d ever want a firmware update if there’s a serious bug that can’t be worked around (Oh, it’s normal that you need to press the espresso button twice, quickly, or it will make tea instead).

        There are no new features.

      3. 1

        Aside from all the humdrum of discussions about how hardware shouldn’t have an expiry date, The article sadly failed to mention that Google’s also working actively to uncouple the actual browser from rest of Chrome OS. That would mean that even when the software updates stop, the browser itself can still stay up-to-date and secure. That’s a great step forward that helps both these upcoming as well as currently supported Chromebooks.