Read this. This article pretty summarizes what I see every day. And when I criticize it, half of the audience doesn't understand my point. They are simply to young and grew up with smart phones and fast lines.
"Software disenchantment": http://tonsky.me/blog/disenchantment/ via firstname.lastname@example.org
@_xhr_ I've been irritated by this for years too.
I attended a lecture on building web sites efficiently a couple years ago. The lecturer asked for a show of hands on who cared about download size. I was the only one putting my hand up.
"You started doing this in the 90s". Yep, I did. 🙄
@_xhr_ thank you for sharing.
@_xhr_ buildings have fat safety margins, as they should.
Machine learning is something you apply to some kinds of problems. Like for instance maybe could apply it to this federated timeline here get just the best ones.
Damn small linux was 50MB, Tiny Core Linux 16MB(not sure what you have with that) Hope that https://postmarketos.org/ makes progress so Linux distros without these issues can be applied here.
As for existing systems, i think wikki de fik erin has a good solution for this.
@_xhr_ I think a stronger case could be made if concrete data were used. As a reader, I'm much more likely to be persuaded when the author cites real-world examples that show how people's lives are being affected. Don't get me wrong, I am moved by the author's passion and am sympathetic to the points being made, but I could see this being easily dismissed as curmudgeonly.
@_xhr_ A lot of modern software releases are ultimately managed by non-engineers. What are decision-makers to do with this op-ed? If I didn't know better, I'd write the author off as a grumpy old-timer complaining about a world that's passed them by. Give me hard data, give me something to show laypeople that could convince them that changing course is worth their time and effort.
@bignimbus @_xhr_ My reaction is similar, but from a different perspective. This is an old, systemic problem: _all_ software grows continually, people were complaining about "bloat" and "cruft" back in the 1960s. That means the solution must also be systemic. We have to look at the incentives and the affordances and figure out what changes would make it _natural_, the thing everyone does without trying, for software systems to stay small and tight even when resources are abundant.
@bignimbus Totally sane approach.
Sadly, I am personally not sure if hard data could convince the key stakeholders to change the current way of doing things. Everybody knows that the corporate page is slow, but we put more and more trackers on it just to measure "another interesting thing".
@_xhr_ that makes sense. Perhaps after a while users will start to demand more - but I would also put a gigantic caveat on all this: computers and networks do things today that are astounding in their utility, complexity, and scale. Things that are commonplace today weren't even possible a very short time ago. The speeds at which applications operate - even the "slow" and "bloated" ones - aren't typically prohibitive.
@_xhr_ Not saying everything is perfect - errors and performance bottlenecks are still really annoying and increasingly common IMO. Decision-makers often shun best practices for shiny objects. But I remain an optimist.
@_xhr_: I've been jumping on that soapbox for almost a decade. I'm not a developer, but I used to teach Visual Basic (nuff said). Now I do Blackboard support at a university.
In theory, Bb is a tremendous learning tool; in practice it's (tremendous bloat + unreliability) squared. We get daily messages from Blackboard advising us about known bugs in the various semi-annual service packs & deployments. At least Bb is conscientious about providing patches regularly.
@_xhr_ dieselben "alten Säcke" die noch mit fehlendem RAM, mieser IO und schwacher Bandbreite kämpfen mussten, pfeifen jetzt drauf und benutzen Slack statt irc.
@datenimperator Das DDR-Bananen-Phänomen. Jahrelang nur IRC und vi per Modem gehabt, deswegen gibt es jetzt nur noch Slack und Atom!!1
@_xhr_ This is why I've gone back to reading the 1980's books on patterns and architecture
Trying to get back there, when things were actually not that bad
When 20MB (yeah MB) was a big database
When you could hold problems in your head
When 200 lines of C were about the most you'd write in any one module because complexity would bite you
Before SQL got all the mad stuff for ranges and things used by the data warehouse crowd
When everything wasn't in a global
@_xhr_ I love this, but how do you get this message through to the business people who are only concerned with mostly WHEN, only sometimes WHAT, and never HOW they get whatever "features" they think will make business work?
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!