> Admittedly, I stopped reading just over half way, but the crux of the argument appeared to be that software should be fast, though I don't recall any justification for that philosophy other than suggesting that it is basically a truth.
Are you suggesting that maybe users (including you and me) should have to put up with painfully slow, stuttering software? I don’t see why his claim requires any justification - to my mind, it should be just as self evident as the fact that inflicting physical pain upon others should be avoided.
> […] modern software developeres tend to aim to be "fast enough" in the way that an structural engineer would choose "strong enough."
But they don’t aim to make software fast enough. My experience last week: Windows 10 file Explorer took ~2.5 seconds to open. Close it and re-open it: same thing. Open it, right mouse click another folder to open a new Explorer window: same thing. Fresh install of Windows 10 on a top of the line workstation-type laptop with 64gb of RAM.
Not all, but a frustratingly large proportion of modern software is dog shit slow.
The reason doesn’t need to spelled out in the article: if the developers of these slow apps cared, they could figure it out. From my experience, it usually looks something like this:
Some developer has an emotional attachment to Protocol Buffers, and will stop at nothing to see its adoption within the org. But their software is pretty heavily invested in JSON. So they rewrite the software to read the existing JSON files from disk (or REST web service response bodies, whatever), and reserialize them to protobuf in memory. Tada! Now we’re using protobufs, great. Of course, nothing meaningful was actually achieved here - they already had a perfectly fine, ready to use, deserialized, in-memory data structure before they added protobuf to the mix. Oh, and that plain struct in memory was faster than traversing a protobuf: the former had small substructures laid out in the same allocation as the parent, whereas substructures in protobuf involves multiple allocations and chasing pointers. Next step: realize that REST is lame, and gRPC is hip. But it’ll be practically impossible to rewrite everything from REST to gRPC, so they do the only reasonable thing: create proxies that sit between the client and server that translate REST requests/responses to/from gRPC! Now that we have that in place, we can add an additional proxy to the mix: Envoy. Envoy is a super popular layer 7 proxy, so it’s gotta be good. What functionality will be used? Any load balancing? RBAC policies? TLS termination? Nope. None of it. But because Envoy is “good”, adding it to the stack with no justification must also be intrinsically “good”, right? Right!
(Edit: do you see how long winded and boring this example is? This is precisely why the author shouldn’t expound on the “why” - anyone involved in the development of needlessly slow software (who isn’t blind to the problem because they are part of it) can recount similar craziness. Adding this to their blog would make for boring reading, and distract from the aim of their article.)
Buzzword/resume driven development, unwarranted layers of indirection (for no gain), absolution of responsibility via appeal to authority (if the top 10 software companies created and/or use some software, then surely we can blindly use that software too and enjoy the same success, despite not giving any consideration to whether it’s even remotely the right tool for the problem at hand), cargo culting, etc.
The reason software is painfully slow usually boils down to lack of critical, rational thought: either out of laziness and/or deferral of responsibility, or because of some emotional attachment to some type of software component.
> Are you suggesting that maybe users (including you and me) should have to put up with painfully slow, stuttering software? I don’t see why his claim requires any justification - to my mind, it should be just as self evident as the fact that inflicting physical pain upon others should be avoided.
I'm suggesting that the blanket assertion doesn't hold true that slow software is painful software. Software can be so slow that it's painful but "slow" from the point of view of absolute does not immediately make something painful.
A counter-example that the author used when describing people with a pride in inefficiency was to quote:
> @tveastman: I have a Python program I run every day, it takes 1.5 seconds. I spent six hours re-writing it in rust, now it takes 0.06 seconds. That efficiency improvement means I'll make my time back in 41 years, 24 days :-)
I'm also asserting that slow and painful software that does what I want is better than fast software that doesn't or that I can't afford.
Heck, I empathize with the author: when I run Slack there is a perceptible delay when I type. Do I want them to fix it? I mean, no, not really. I'd personally rather they provide an offline search mechanism or a way to write direct CSS for theming. It's something that is annoying but it is less annoying that missing new features or the price going up. Likewise, I could use Vim for editing if I really wanted to, but I'd rather have the featureset of IntelliJ.
> I'm suggesting that the blanket assertion doesn't hold true that slow software is painful software. Software can be so slow that it's painful but "slow" from the point of view of absolute does not immediately make something painful.
I agree with this. Though my interpretation of the blog post was that the complain was directed at the subset of "slow" software that is specifically "perceptibly slow, to a frustrating degree".
> A counter-example that the author used when describing people with a pride in inefficiency was to quote:
>> @tveastman: I have a Python program I run every day, it takes 1.5 seconds. I spent six hours re-writing it in rust, now it takes 0.06 seconds. That efficiency improvement means I'll make my time back in 41 years, 24 days :-)
Yeah, that quote (and attached commentary) did seem a bit out of place.
> I'm also asserting that slow and painful software that does what I want is better than fast software that doesn't or that I can't afford.
I agree here.
I suppose whether the blog post is is likely to resonate with someone comes down to one's prior notion of why frustratingly slow software is the way it is.
Some may believe that such software is developed by experienced, motivated developers who want to do their best work, but run up against a hard choice between allocating time to important features vs clever/tricky/novel optimization.
Others, like myself (based on my firsthand observations), believe that software can be just as feature complete while also being "fast enough (to not be frustrating)" all while using the same resources (dev time, money, etc). Developers just choose not to. It's not that anyone consciously thinks "hey, I think I'll go out of my way to write slow software" -- in the same way that (almost) no one thinks "hey, I'm going to strive to be morbidly obese"; rather, it's the lack of a conscious decision to employ self discipline and:
- Do not add layers of indirection because it "feels" right (I've seen countless changes that, upon questioning, can't be motivated beyond "I dunno, it 'felt' right"); instead, think through what you're doing. Just because you've thumbed through a design patterns book, or saw a blog post about dependency injection, or recently discovered runtime type reflection, doesn't give you license to cargo cult any of these things. If it was discovered that a bridge was constructed out of some material because the engineer(s) thought it "felt right", because the raw materials were "pretty" and "sparked joy", or maybe even "tasted good", I'm sure almost everyone would be horrified at such spectacular negligence. Somehow, similar behavior in the software world is perfectly acceptable.
- Do not add libraries and frameworks and orchestrators and pipelines because your ADHD compels you to play with new, shiny things. I have ADHD, and the compulsion is there, but I choose to ignore it.
- Do not use some tech just because it's popular, with zero critical thought, thus applying the wrong tool to the problem at hand. That's a recipe for slow software that requires more development time, as whatever time you save by not engaging your brain will almost certainly be eclipsed by the time wasted trying to contort the tool you're abusing.
- If you're about to spend the next hour working on something, first spend 5 seconds to see if the standard library has a ready-to-go, optimal solution to your problem. An example from firsthand experience: early in my career, I worked on a desktop GUI application, using Windows Presentation Foundation (WPF). One of our devs needed to add an underline to a text label. At our standup, he reported that he expected to spend the rest of the day working on that one change. He and the lead developer discussed how he could develop a new, custom control, and how the custom rendering routine would work, and gotchas to watch out for (naturally, you'd need to gather subtle font/layout metrics to know where / how wide to draw the underline), etc. I mentioned that an underline decoration is something that the standard WPF text label control already supports out-of-the-box -- the change would be something as simple as adding underline="true" to the respective XML element that declares that control. That was uncritically shot down with "No... no. I don't think that's a thing". The only reason we didn't lose 8 hours+ of developer time that day was because I did a 5 second Google search after that meeting, found the MSDN documentation page for that "underline" setting, and sent it to the developer, and he chose to implement that 5 second change instead of creating a custom component. Of course, the lead developer rejected the changes as "this wouldn't compile", though I had already compiled and spun up the app; because I'm diplomatic, I asked if he could look at something, and inquired "so, I know this underline probably isn't quite what we need, but I was curious if you could give some pointers on how our custom implementation would need to differ?" -- he was stunned, finally realized that the existing, bog standard control already had this functionality, and then approved the change.
I would bet anything that 99% of painfully slow software could be pretty snappy (or at least "snappy enough") if the developers thereof wouldn't create more work for themselves by doing inane things. No hyper optimization, bespoke algorithms, nor heavy R&D required.
I mostly see bloat created for other reasons. Think about situations like Docker containers replacing single applications (and dragging entire Linux userspace installation with them). Deploying in Kubernetes with its own CNI as well as DNS server and a bunch of other networking-related stuff while the network in your datacenter already does all of that. Packaging the whole Python virtual environment into a DEB or RPM package instead of shipping just the library you want users to install.
This bloat is harder to deal with, on organization level, because people creating it justify it by saving on development effort necessary to make the product leaner. There's no financial incentive to not use Docker for deployment (and spend developer's time ensuring the code works on different platforms with different libraries).
And software industry isn't the only victim of this situation. First time I ever encountered this was in a... church. American missionaries coming to the former Soviet republics would bring with them pocket Bible for free handouts. Since I studied printing, to me this pocket Bible was strange in many ways. It was printed on paper lighter than 20 g/m^2. This was unheard of in Soviet printing industry. If it ever tried to produce such paper it would simply fall apart because they didn't have access to the technology necessary to produce plastics that held this paper together. Because the paper was too thin, it required a lot of "filler" (again, more plastic). And that made it worse for recycling. It was printed using offset machine. Soviet industry didn't print literature using offset machines. They didn't have the technology for making precise high-resolution plates necessary for such printing, so letterpress printing would be the way to do it. But, letterpress makes a noticeable difference in texture of the page, it also pretty much prevents you from using "unorthodox" font sizes, ensuring that the font's author could see exactly how letters are going to look on a page, making the overall experience much more pleasant.
All in all, it was kind of a technological marvel I knew I couldn't achieve with what I had / knew, on the other hand, all this technology was intended to decrease cost at the expense of marginal drops in quality. In truth, at the time, I didn't think this way. I saw the technological marvel part, and didn't notice the drops in quality. The realization came a lot later.
Are you suggesting that maybe users (including you and me) should have to put up with painfully slow, stuttering software? I don’t see why his claim requires any justification - to my mind, it should be just as self evident as the fact that inflicting physical pain upon others should be avoided.
> […] modern software developeres tend to aim to be "fast enough" in the way that an structural engineer would choose "strong enough."
But they don’t aim to make software fast enough. My experience last week: Windows 10 file Explorer took ~2.5 seconds to open. Close it and re-open it: same thing. Open it, right mouse click another folder to open a new Explorer window: same thing. Fresh install of Windows 10 on a top of the line workstation-type laptop with 64gb of RAM.
Not all, but a frustratingly large proportion of modern software is dog shit slow.
The reason doesn’t need to spelled out in the article: if the developers of these slow apps cared, they could figure it out. From my experience, it usually looks something like this:
Some developer has an emotional attachment to Protocol Buffers, and will stop at nothing to see its adoption within the org. But their software is pretty heavily invested in JSON. So they rewrite the software to read the existing JSON files from disk (or REST web service response bodies, whatever), and reserialize them to protobuf in memory. Tada! Now we’re using protobufs, great. Of course, nothing meaningful was actually achieved here - they already had a perfectly fine, ready to use, deserialized, in-memory data structure before they added protobuf to the mix. Oh, and that plain struct in memory was faster than traversing a protobuf: the former had small substructures laid out in the same allocation as the parent, whereas substructures in protobuf involves multiple allocations and chasing pointers. Next step: realize that REST is lame, and gRPC is hip. But it’ll be practically impossible to rewrite everything from REST to gRPC, so they do the only reasonable thing: create proxies that sit between the client and server that translate REST requests/responses to/from gRPC! Now that we have that in place, we can add an additional proxy to the mix: Envoy. Envoy is a super popular layer 7 proxy, so it’s gotta be good. What functionality will be used? Any load balancing? RBAC policies? TLS termination? Nope. None of it. But because Envoy is “good”, adding it to the stack with no justification must also be intrinsically “good”, right? Right!
(Edit: do you see how long winded and boring this example is? This is precisely why the author shouldn’t expound on the “why” - anyone involved in the development of needlessly slow software (who isn’t blind to the problem because they are part of it) can recount similar craziness. Adding this to their blog would make for boring reading, and distract from the aim of their article.)
Buzzword/resume driven development, unwarranted layers of indirection (for no gain), absolution of responsibility via appeal to authority (if the top 10 software companies created and/or use some software, then surely we can blindly use that software too and enjoy the same success, despite not giving any consideration to whether it’s even remotely the right tool for the problem at hand), cargo culting, etc.
The reason software is painfully slow usually boils down to lack of critical, rational thought: either out of laziness and/or deferral of responsibility, or because of some emotional attachment to some type of software component.