3 ms·
Oh I agree with the potential technical benefits. I think the business justification is pretty weak, though. The business benefits you listed are defensive. Th
by mrkurt 4y ago
Oh I agree with the potential technical benefits. I think the business justification is pretty weak, though.
The business benefits you listed are defensive. That is, if the business is doing well, those are things you might optimize for. The same way you'd, say, try and decrease power consumption.
There are companies where an order of magnitude decrease in ongoing costs opens allows a whole new kind of product. But order of magnitude increases in the things you just listed are rarely developer process improvements or refactors.
Customer happiness is a fun one. If you have a buggy or unreliable app, you'll frustrate customers (I am very aware of this, if you check my post history). You won't _make them happy_ just by building reliable software though.
As someone whose #1 priority is reliability right now – fixing bugs faster very low on the list of things that matter. The problems users have with our platform are a combination of the wrong architecture, and non existent tooling for customer communications.
Which gets back to the original post. We want to hire devs who can identify out what our users need most today, figure out what we can do about it (if we can at all), and then implement what makes sense.
- pmarreck 4y agoI see your points, and were I at a company currently (I'm looking), I would prioritize the business-leading things, of course. > #1 priority is reliability Yeah, mine is too. (In fact, I think we're approaching a crisis of reliability out there, if we're not there already.) That's why I went with Elixir, and it's paid off so far. The only time the site's been down in years is due to my hosting provider, not me... (So of course I'm looking for another hosting provider...) I have to deal with the occasional 500 errors as well, which, as it turns out, are also largely due to my hosting provider and not my code (but sometimes my code...). The thing I realized about reliability way too late is this: The utility of a service (or a person) to a person drops off VERY quickly if you dip below 99% reliability (or arguably, 99.9% reliability). Something (or someone) that is 90% reliable is practically useless, because it is bound to fail at the worst possible time. So in all the software I write, I focus on this, and in all my relationships with people (or orgs, or bosses, or my son, or my S.O.), I know that if I commit to them, I must be as reliable as humanly possible because the costs of every slip-up are huge and rise exponentially as they accrue. An example of a service that is just unreliable enough to be a huge annoyance (which has also caused bad communication failures as well in my experience) is SMS. SMS failures are the worst.