I was talking to a couple of different people about the software they use in their industries, and the sentiment ranged from "meh" to "ugh." The complaints were pretty common stuff... it's too slow, doing this is awkward, doing that is a workaround, it's too hard to adopt something else... the usual. As someone who has made a (somewhat lucrative) career out of making software, it kind of hurts to hear this. What is my profession doing? Does anyone like their software?
This calls into doubt my own self-evaluation over what I think I've delivered over the years. For the most part, I think the stuff that I've touched and/or managed has mostly resulted in things being better than they were. I've been bullied into work that shouldn't have been done, with suboptimal results, sure, but I'd like to think that anything I've believed in was better. To really unpack that, I think I have to consider how software gets crappy.
The most obvious thing is that time passes. As time passes, a number of things change. The number of users goes up, the available technology changes and improves, experts leave (or worse, are let go for not-great reasons), documentation is poor, different systems are glued together in hacky ways, features no one wanted are built and never evaluated, new parts come in via acquisition... and I could go on all day about these. I had a pretty long list as I started to write this, but the theme is the same. Over time, people don't react to the symptoms of the passage of time.
As a business leader, I completely understand this. Heck, even as a technical manager, I will push back on things that have little obvious immediate value, or a long time until value is realized. In fact, this might have been the hardest nerd thing to unlearn as a leader, that just because it's technically interesting doesn't mean we should do it. But you do have to be an oracle of sorts. Assuming that you can have the kind of clarity necessary to understand what your customer needs the most, you have to look at your software and look for things that enable the delivery of customer needs.
What I've learned over time is that trying to separate different problem domains, making them so they can do work independently of each other, and change without breaking each other, makes it a lot easier to maintain and improve. Not coincidentally, this is referred to as domain-driven design, and it can get as serious as religion in some circles. These days we think of this naturally, because of the way that cloud resources can be used, but even 20 years ago, in the world of monolithic applications with a single database, you could build things this way. The thing is though, most projects start out as these tightly-coupled, monolithic things because that's how you prove that the software is valuable in the first place, and do it quickly.
For example, say your system has a customer record, and it has their name and address. Now you want to know how much they've spent this year, so you keep a running total and just keep it with the customer's other information. But then the year changes, you want to split out their widget purchases from their wheel purchases, etc. It seemed like a quick win to conflate the customer's information with their spending habits, but that turns out to be a bad idea. I've seen this countless times, where an aging system has a hundred different data points attached to the customer that have nothing to do with who they are.
The problem is that it's hard to go back and re-do stuff. Again, if you're that business leader, or mature technical manager, "It's working today, so it's not valuable to revisit that." And that's always true, until it's not. You try to add this thing, and the blast radius of doing so makes things more complicated and even harder to change. This ultimately affects the end users, who now hate their software.
It's not purely a technical problem. Product leaders and designers do the same thing by bolting on a button here or there. Have you ever seen some of the interfaces on "enterprise" software? You can't figure it out.
So do I like any software? I've written a bunch of times about how much I like the cloud music player that I built. A lot of the video games that I've liked over the years are certainly software. The home automation software seems like it barely works together, but I love telling a speaker "Merry Christmas" and the whole house lights up. As I get more familiar with MA Lighting, I'm starting to like it more and appreciate what it can do. I like JetBrains Rider, the app I use to write code. I really like DaVinci Resolve for video editing, even though I still don't know it super well. I like Quicken Simplifi, which I started using this year to track my personal finances.
But virtually all of the corporate enterprise software that I've used over the years is kind of garbage. I'm talking about the HR stuff, expense reporting, CRM, that sort of thing. Google's G-Suite isn't bad, I suppose. My purest, most refined hatred is for Jira, which unfortunately seems to have become a de facto standard for software project organization. I feel like it has to be tolerated.
The outcome of all of this is that I end up talking to my fellow software buddies and we get to talking about how we could do so much better. And the truth is, I'm sure we could, but we are not good at selling things.
No comments yet.