3 ms·

Best practices exist for a reason. If you know for a fact that small lightweight software is not what you are building, and your codebase will probably be bazi

Best practices exist for a reason. If you know for a fact that small lightweight software is not what you are building, and your codebase will probably be bazillions of lines, you can often guess that you probably are gonna need it. If you want to make Chrome or LibreOffice, you're probably going to need some abstractions. I've very rarely seen any true IObjectFactoryInstanceMethodAdderMixinAbstractInterfaceBean level stuff, most of the complexity people complain about serves a purpose, at least that I see. It facilitates building complex software with a large amount of reuse and with way more dev effort than one wants to make. Simplicity is usually harder than complexity, and a lot more design decisions to get right. Complexity is often just following a template. Need to encode something? What's the most popular JSON encoder in your language? Need web stuff? Pick the best practice one, you know it will be around a while and you team already knows it. You can go overboard, and simplicity has virtues, but it's pretty cool how well everything can just come together without much friction if you really, really aggressively avoid doing anything interesting and "Just do what the industry standard is".

nousermane 4y ago
> you know for a fact that small lightweight software is not what you are building Maybe this is the point to stop and ask yourself, if you're doing it right? There is no industry standard for complexity. It's the "dd" vs "balena etcher" argument. There is very small benefit to the average end user from literally 2000x increase in size/complexity, and for experienced user, fancier tool is actually worse (can't do "ssh foo cat blah | gunzip | dd")
- eternityforest 4y ago
  dd vs Etcher is actually my canonical examples for why I'm totally fine with complex software. dd doesn't verify after flashing. It doesn't alert when you're finished. It doesn't predict the time remaining. It On Reddit, I see about one "I wiped my disk with dd" post every month or two(Although I suppose using by-path might have prevented some of them, it's slightly more obvious). Even more relevant is the raspberry pi imaging utility that also lets you set some configuration options when flashing. It doesn't do anything you couldn't do with a shell script, and Etcher certainly doesn't actually need to be that big.... but it already exists, and using etcher instead of a custom script is one less custom thing to maintain. I can tell anyone on any platform "Oh yeah just use Etcher" and have a near guarantee they will know exactly what to do and not break anything. 40-80MB seems like a lot. I'm pretty sure you could build a clone in PyQt in a weekend. Etcher is also missing some features(I'd really expect it to be a full studio with plugins to configure the images, make backups, and test in QEMU, considering how big it is). But Etcher exists already. Using it is one less thing to worry about, one less custom script to possibly maintain, and one less possible mistake that could wipe a disk.
c22 4y ago
The difference I've noticed is that the complex stuff might bolt together quickly, but it's all broken 6 months later as the shifting sands that underpin it are blown by the prevailing winds of fashion. This sort of software requires constant maintenance, often by large teams, or it immediately begins to bitrot. Well-thought-out simple stuff, on the other hand, can last for decades and often is quickly adapted to novel devices and environments.
- kaba0 4y ago
  The converse can be just as true, some indie dev instead of a feature-packed, stable dependency will reinvent the wheel because that a subset of those should be enough he/she thinks. Now that code can only handle 80% of the cases because it turned out the complexity of the dependency was not meaningless, and it is buggy and much less maintainable.

nousermane 4y ago

> you know for a fact that small lightweight software is not what you are building Maybe this is the point to stop and ask yourself, if you're doing it right? There is no industry standard for complexity. It's the "dd" vs "balena etcher" argument. There is very small benefit to the average end user from literally 2000x increase in size/complexity, and for experienced user, fancier tool is actually worse (can't do "ssh foo cat blah | gunzip | dd")

eternityforest 4y ago
dd vs Etcher is actually my canonical examples for why I'm totally fine with complex software. dd doesn't verify after flashing. It doesn't alert when you're finished. It doesn't predict the time remaining. It On Reddit, I see about one "I wiped my disk with dd" post every month or two(Although I suppose using by-path might have prevented some of them, it's slightly more obvious). Even more relevant is the raspberry pi imaging utility that also lets you set some configuration options when flashing. It doesn't do anything you couldn't do with a shell script, and Etcher certainly doesn't actually need to be that big.... but it already exists, and using etcher instead of a custom script is one less custom thing to maintain. I can tell anyone on any platform "Oh yeah just use Etcher" and have a near guarantee they will know exactly what to do and not break anything. 40-80MB seems like a lot. I'm pretty sure you could build a clone in PyQt in a weekend. Etcher is also missing some features(I'd really expect it to be a full studio with plugins to configure the images, make backups, and test in QEMU, considering how big it is). But Etcher exists already. Using it is one less thing to worry about, one less custom script to possibly maintain, and one less possible mistake that could wipe a disk.

c22 4y ago

The difference I've noticed is that the complex stuff might bolt together quickly, but it's all broken 6 months later as the shifting sands that underpin it are blown by the prevailing winds of fashion. This sort of software requires constant maintenance, often by large teams, or it immediately begins to bitrot. Well-thought-out simple stuff, on the other hand, can last for decades and often is quickly adapted to novel devices and environments.

kaba0 4y ago
The converse can be just as true, some indie dev instead of a feature-packed, stable dependency will reinvent the wheel because that a subset of those should be enough he/she thinks. Now that code can only handle 80% of the cases because it turned out the complexity of the dependency was not meaningless, and it is buggy and much less maintainable.