> 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 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.