My Business Is Dying

Really, upgrading in the background is not calm technology to me: Windows Upgrades almost daily and my PC slows down, Firefox upgrades in the background and my tabs become unresponsive daily. I prefer the apt-Linux approach, even Ansible, or chocolatey. Anyway, I am not surprised that there are different definitions of what calm means (no offense!).

I believe there are good ways and bad ways to the background updates.

macOS and iOS doing updates when you are not looking is good because they store your app state most of the time.

Some macOS programs' "We have downloaded the update, it'll update silently when you exit" is also nice and kind way of doing it.

Firefox recently remedied its "We updated in the background but broke the runtime" problem for some months now on Linux and macOS, from which I observe.

However nudging, aggressive updates, forcing user to stop or take breaks are not calm technology. I accept that wholeheartedly.

I’m smiling a bit reading this thread because I went essentially the opposite way: started contracting in 2010 when my grad school stipend ran out, in Feb 2020 (kind of lucky timing…) one of my clients convinced me to come on as FTE #2 at their startup (I’d done a 6-month prototyping gig for them in 2019 that was responsible for them unlocking their first tranche of funding). Have stuck around since then because the work is compelling and to some degree I’ve shaped the engineering org into what I want it to be, even though we’ve hired people above me (it’s kind of neat and weird hiring your own manager so that you no longer report direct to the CEO)

Anyway, as far as I can tell, the engineering teams that I was paid to help, I believe, generally loved me. The work I’d do generally fell into one of three buckets:

- early-stage prototyping work, where there was no engineering team yet and I was laying the foundation for v1 of a product

- modernization work, where a company has a product line that’s sitting generating revenue but there’s no engineering capacity to actually make v2. This was often more on the embedded side but occasionally stuff like pre-ARC Objective C -> Swift. Everyone’s too busy working on some other thing and the good-but-crusty product is starting to die due to lack of attention

- rescue work, where the engineering organization (management + ICs) have gotten themselves into a situation they’ve realized they can’t get themselves out of on their own. Often performance, scaling, or velocity-related, almost always with an element of pathological engineering culture.

The first two cases aren’t as relevant, but the third type was always a hearts & minds campaign. The outcome was two-fold: fix the software, fix the team.

First step: take the team out for lunch without their manager. To the loathing comment above, not everyone would take me up on the offer, but I could usually get enough of a critical mass together. Two objectives: convince them that I do not, under any circumstances, want to work with them long-term; convince them that I was on their side. Get them talking about what’s wrong, ostensibly about the product, but this would frequently pivot to the structural organizational problems that led to the product being how it was.

From there, put together two plans. Plan 1 was for how to tackle the software problem. Plan 2 was how to fix the engineering org. Typical situation was they had some ideas on the first part and LOTS to say about the second part. The connection between the two was they often had a good high-level idea about how to fix the software but didn’t have the specific skill to do the fix and didn’t have time to learn.

Then I’d start working both problems in parallel: knock out a quick win on the software side, do a lunch & learn with the team and their manager to explain what I’ve done, what tools I used if I used anything exotic, discuss next steps, and discuss whether someone else on the team wants to work together on the next thing. Meanwhile, I’m watching the team (incl. management) and the complaints that I got from them over lunch and while working with them. Looking to see which of those complaints I can see in the day-to-day work environment and who to… blame isn’t the right word, but figuring out who I need to nudge in which direction to make the problems that led to my involvement go away.

This usually went through a few iteration loops but I was always clear to everyone involved that my goal was for the team to not need me anymore. That was the outcome: problem solved, team can solve the same kinds of problems on their own without me. I’m available if you ever need to hire me again, I’m here if you get stuck on something tactical and can help out for a few days here and there.

If my goal was to get fired, how do I know that I did good? Direct feedback from ICs was one way. I smoked a fair bit back then and the number of times I had people come up to me outside during a coffee/smoke break and just say “hey man, I really appreciate what you’re doing here, I’ve learned a lot about ____”. The other one: referrals. Maybe 20% of the work was inbound LinkedIn cold calls, while the other 80% was referrals from existing clients (or callbacks) with about a 50-50 mix of that being management or IC referrals. Work with a team for 3 months, a couple months later get an email “hey so I was out for beer with XXX and I think you might be able to help me…”

I don't understand how we all just stood by and let "monthly subscription" sneak in and become the dominant form of paying for software (and entertainment/media, too).

Almost everything else in my life is a one time purchase. I pay for the thing, I use it forever. I would never buy a vacuum cleaner subscription. Or a pressure washer subscription. Why should I need to endlessly pay for software?

The usual excuses from developers:

1. But I need to maintain the server and that's a monthly cost!

Nope. Tethering your software to a server was your choice, not mine. I shouldn't have to pay for your decision. I have lots of perfectly good software on my computer that work fine without your server.

2. But it costs money to constantly be developing and publishing updates!

Nope. Nobody is asking you to constantly change your software. Generally, I don't want your updates. The software met my needs when I bought it, and I don't want you to change it, and I certainly don't want to keep paying you just so you can keep changing it.

We need to go back to treating software like it was something you bought in a box off a store shelf and that was it. No recurring payments. No updates. No accounts. No nagging. No telemetry. Just a box of bits that I hand over money for once.

The problem is that web applications have an ongoing monthly cost to maintain for bandwidth, usage, disk space, etc.. so the only solution is to charge a subscription.

Yes, traditional software also has a cost for maintenance and features but users could opt out to not pay for them.

I personally rather to either pay per usage, pay for the full year if it's valuable enough to purchase a license for desktop / mobile apps if possible.