13 ms·

Software Disenchantment (2018)

230 points by ShowalkKama 4y ago

thr0wawayf00 4y ago
> So it’s our mission as engineers to show the world what’s possible with today’s computers in terms of performance, reliability, quality, usability. If we care, people will learn. And there’s nobody but us to show them that it’s very much possible. If only we care. Software engineers by and large care and yet we can't even get the businesses we work for to care, the stakeholders that performance would matter to arguably the most. I think the average person is even more apathetic about a topic like optimizing app performance.
- tsss 4y ago
  I have made very different experiences. The programmers don't care either. They just want to pump out features, no maintenance, no documentation, no long-term improvements.
  - cs137 4y ago
    That's not what the programmers want. It's how they're incentivized. If you have to meet your "they're not deadlines but, really, they are" sprint targets, then what can you do but minimally complete the tickets assigned to you and hope not to step on anyone's toes? It doesn't help that good programmers get flushed out of the industry due to conscience and age, only to be replaced with cheap, shitty ones.
    - tsss 4y ago
      No, in my case that's really what they want. I think our project management would totally give us the time to improve something, if we can argue that it's needed. It's really one or two developers who block everything that isn't the absolute minimum possible amount of work or their own pet idea.
      - mgkimsal 4y ago
        > I think our project management would totally give us the time to improve something, if we can argue that it's needed. You shouldn't have to argue for it. It's something "project management" should care about as a top-level concern, scheduling time for it. Stability, documentation, tests, performance, security - these are all "features" just as much as "make a button dump a CSV for a user".
        tsss 4y ago
        I mean, they do to the extent that they can. We have a story template that specifically mentions performance, monitoring, security and documentation requirements. We also have weekly meetings to discuss technical issues and a dedicated backlog where devs are supposed to put purely technical stories, but it is usually empty. When the prevaling philosophy of the dev team (or its most vocal members) is "'good enough' is good enough", then there's not much the project management can do short of forcing a minimum amount of maintenance tasks. Of course, project management is also happy if they have more capacity for feature stories, so the impulse has to come from the dev team.
        tacitusarc 4y ago
        Often (good) PMs assume that those tasked with making technical decisions implicitly understand all the listed concerns are, in fact, requirements. They are then surprised when the engineers explain they didn’t prioritize those things when doing the work.
  - ratww 4y ago
    I also share your experience. Never saw management or PO complaining about developers taking time to optimise. I actually never even saw an experienced developer taking an inordinate time to optimise something. It's always refactoring and rewriting that takes too much time (and often causes performance regressions). Developers however are quick to point that optimisation is "not in the interest of the business", as can be seen in this very topic, or that something is "good enough" since a lot of people are using.
  - spaetzleesser 4y ago
    "The programmers don't care either. They just want to pump out features, no maintenance, no documentation, no long-term improvements." That's how people are taught. In most companies nobody cares about quality. getting stuff out quickly is where the money is. Slow, deliberate work doesn't pay.
brunojppb 4y ago
I did the Portuguese translation of this article for Nikita back then and it’s interesting to read this article again in 2022. While things are still bloated, I am very hopeful for the future after seeing many cross-platform initiatives written in Go and Rust. I hope to read this article again in 2026 and see faster, less resource-consuming apps running on our machines.
- jackosdev 4y ago
  Yeah there has been some great efficient software coming from the Rust and Go communities, ripgrep, nushell, lazygit, helix to name a few I use everyday
bbbobbb 4y ago
The text resonates with me but there isn't much practical advice. What should I do as a normal developer working on normal business products? I try not to do obviously slow and stupid stuff but it is not the main focus. It does mention it but just to reiterate: The business value of getting things out is larger than getting things right most of the time. The architecture are bloated micro-services, the infrastructure is overcomplicated, the response times are order of magnitude longer than they ought to be. But there is no time to care. The next shiny feature or integration or whole business case is waiting to be implemented and shipped. We cannot afford to spend time on improving things people don't complain about over things that bring more money. I guess that is where the disenchantment part comes in. Most companies are not in business of engineering stuff well if that is not what makes them money.
- nine_k 4y ago
  Developer's time is much more expensive than CPU's. So much more CPU's time is spent ("wasted") to save some amount of developer's time. This includes developer's s study time, that is, hiring less educated and experienced developers. In 1990s we had a similar effect: the CPU performance and RAM sizes grew so rapidly that "poorly written" and "bloated" software became "butter-smooth" and "lightweight" in a couple of years. Now we have the cloud instead, when spinning a dozen more instances or upgrading to a slightly more expensive plan gives the performance boost that solves many bottlenecks (much) cheaper than paying a team of 3 developers to spend 6 extra months to do things right. The endless CPU growth gravy train stopped in mid-2000s. I wonder when the endless cloud scaling train will slow down materially.
  - bbbobbb 4y ago
    It's not just dev time vs cpu time. The thing the article mentions and what I was trying to echo is that software is slow and overcomplicated despite that. It would be unusable without fast hardware. But people are used to programs being slow and bloated. People and companies are rarely willing to pay premium for efficient programs. So here we are, gluing stuff together so that we're fast to market with every next feature while collectively wasting lifetimes as our apps load and perform basic actions. I am not even saying it's wrong. There are plenty of things I'd rather have now and slow than later/never and fast. Nor I am saying given the time I'm capable of making all our software significantly leaner and faster. I am just echoing the disenchantment and some frustrations.
sp332 4y ago
That sync conflict window doesn't force you to lose data. Just check both boxes and you keep both copies. And the python situation was really bad, but things have improved a lot in the last 4 years.
- ptx 4y ago
  The confusion is understandable since the UI designer made the checkboxes look like radio buttons.
phkahler 4y ago
Ironic that I was offered a simplified version of the article to read...
mrob 4y ago
Meanwhile, I'm using a 13 year old desktop running Debian Unstable and it feels even faster than when it was new. It's subjectively faster than an M1 Mac Mini, despite the Mac beating it in benchmarks. I attribute this to two main causes: ruthlessly deleting/disabling everything I consider bloat (e.g. animations, text anti-aliasing, gradient fills, rounded corners, transparency, compositing, Javascript, anything wireless etc.), and using a low-latency gaming keyboard/mouse/monitor. Performance is available if you want it. But I think most people prefer aesthetics.
- jolux 4y ago
  I find text a lot harder to read without anti-aliasing.
  - mrob 4y ago
    To be honest, I doubt disabling anti-aliasing makes any perceptible performance difference itself (although it gives me sharp text without needing 4K, which probably does). But your comment shows the important of customization. I disabled things I personally considered bloat. Other people will consider different things to be bloat. Software should give you that freedom (and Free Software gives you the ultimate freedom to customize).
    - password4321 4y ago
      "Ain't nobody got time for that!" Actually, I would be interested to learn how much time you've invested in customization, especially if there were points when the system became temporarily unusable.
      - mrob 4y ago
        Almost certainly more time than the customizations have saved me. I still consider it worth doing, because I enjoy doing it, and it makes the computer more pleasant to use. I have made the computer temporarily unusable several times, but I have an old netbook too, so I'm never stuck without a usable computer while I fix it.
hermitcrab 4y ago
The old engineering adage is: cheap, fast, reliable - pick 2. Or maybe < 2 with software. And the end of the day most people don't want to pay what development of fast and reliable software costs and businesses know that. So we end up with the shoddy bloatware that are prepared to pay for. If you don't like that, start your own business and write software that meets your standards. If you are too purist, you might find it a struggle to survive financially up against less scrupulous competitors.
bob1029 4y ago
It would seem this is all just a matter of constraints and objectives. It's not that we are unwilling or unable to make things faster. For instance, when presented with the task of porting Quake to the GBA, we somehow find the means to make this happen, despite the underlying CPU only operating at 16.78 MHz. Playable frames per second are achievable on that system. Scaling "GBA Quake"-levels of optimization up, you could probably run thousands of simultaneous clients off a single AMD system today - regardless of GPU capabilities. But, I don't think the market is demanding that kind of experience anymore, especially not at that kind of scale. The point I would like to make: High quality experiences only seem to manifest when enough adversarial pressure has been applied at design/architecture time. This is not just limited to software.
rektide 4y ago
Focusing on the little unpleasantnesses distracts from seeing a bigger picture. The net software experience hasnt changed or improved much. There's a lot of fine tuning & apps getting tweaked, but the platform of computing- to users- has been locked at the same fixed boring low-power level for well over a decade. If you want to be disenchanted, do it from a macro perspective.
DeathArrow 4y ago
I think the biggest wave of the bloat started when SPAs became a thing. After that, fronted web developers thought they can write mobile and desktop apps, so the bloat reached mobile and desktops, backed by repurposed web technologies.
- dgb23 4y ago
  There are plenty of desktop apps that are bloated and slow and plenty of web based apps that are fast and light. Thinking of Figma (web based) vs Adobe XD. The former "installs" much quicker, does cooler things, is more useful, more responsive. The solution to the problems mentioned in the article is not "use technology X", it is about shifting focus on quality.
- intothemild 4y ago
  I tend to agree here. I don't blame SPAs (not that i think you are), but it does feel like there is correlation between SPAs rise in usage and with the frontend becoming worse. Not that it's the tool, but the welder of the tool. I'll explain, I think that basically a lot of frontend engineers started using SPAs for too many different usages... Like using a SPA instead of a static page for a really simple basic website.. to me this is like when a meeting could have been an email. Or adding in so much tooling to their site which doesn't really solve any problems except make new problems, so now there's more tooling for that. (read state management, client side routers) I remember at a <very popular SPA> conf I spoke to the two guys who made a very popular framework for building that popular SPA, they asked me how my serverside project used express.js's router... Like the questions they had were along the lines of "how can you do (insert basic routing thing here) in express?". The only exposure to express they had was a catch all route to their apps main clientside router. I was stunned... They were aware there was this tool, and ignored it.. instead deciding that they could do better. To me this was post SPA frontend in a nutshell.
  - ChadNauseam 4y ago
    You acknowledge that it's the wielder of the tool, but I feel a need to repreent the SPA evangelism strike force because they're just so freaking cool. The web is a UI framework with features that are actually pretty hard to find elsewhere. It has native support for: tabs, forward and backward, zoom, and coolest of all, links so you can send the current UI view of an application to someone who's never heard of it before and they can open it up in seconds. All of those apply to regular websites too, but SPAs allow you to write actual apps in a way that doesn't want to make you pull your hair out. And it's often possible for a well-designed SPA is indistinguishable from a native site. I maintain my personal website as a SPA. When I posted a monad tutorial on my site [0] to HN, not one person complained that my site is slow (it isn't) or that it doesn't work with JS disabled (it does [1]). Plus, when you hover over a link, it uses some SPA magic to prefetch the page you're going to visit, so the transition is even faster than it would be on a typical site. This is the archetypical case of "using a SPA instead of a static page for a really simple basic website" and I think it works really really well. There's definitely some room for improvement. I'd love to be able to make it a bit smaller by rewriting it in Rust through WebAssembly, but it's not quite there yet. [0]: https://news.ycombinator.com/item?id=30762281 https://news.ycombinator.com/item?id=30762281 [1]: except on pages that can't be implemented without JS, like https://chadnauseam.com/reasoning-quiz/ https://chadnauseam.com/reasoning-quiz/ or https://chadnauseam.com/productivity/rational-breaks/ https://chadnauseam.com/productivity/rational-breaks/
Ygg2 4y ago
> On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. A 3D game can fill the whole screen with hundreds of thousands (!!!) Yeah. Just update a tiny rectangle. And check Unicode validity. And render the Unicode character And re-do highlight. And spawn a box with autocomplete. Or not. And run the AST analysis. And depending on language check if there is an extension dealing with it. List goes on. I dislike the simplification that the article glosses over. Games are fast because they do one or few things that GPUs are great at. Text editors aren't as fast because they do a bunch of things that aren't as easily ported to a GPU.
- anonymoushn 4y ago
  Unicode validation runs at gigabytes per second. Text rendering is a tiny, tiny subset of game rendering. Not sure about highlighting, sounds like a mix of parsing and game rendering, so that's likely again to be one process that can run at gigabytes per second and another process that is a tiny subset of a process that often runs at 240Hz these days. Autocomplete, no clue, probably this could also be fast? You're like doing a lookup into an inverted index or a hash table or a range tree or something? So it takes like less than 3 microseconds to decide what the contents of the box should be? Oh, it doesn't, because you decided the way this should work is that several different processes should communicate with each other using JSON-RPC just to figure out what goes in the autocomplete box? Yeah, okay, sounds like a problem with the design then. Notably World of Warcraft does not send json over sockets between multiple local processes to decide how wide the nonempty part of each mob's health bar should be every single frame, and maybe one day we could try to figure out whether there's a reason for that.
  - Ygg2 4y ago
    >Code validation runs at gigabytes per second. You sure about that? I remember UTF8 validation being a major source of slowdown when parsing XML in Rust. Branches kill CPU perf. And UTF8 has branch on every non ASCII char. Nvm. Those methods use SIMD tricks, which while neat are hard to generalize. Also not sure what JSON-RPC is referring to? LSP? Are you arguing that JSON is suboptimal? Like maybe, but it's close enough to rival binary formats. Plus you can parse GB/s of JSON. Even text editors that forgo LSP have speed issues, unrelated to JSON.
pknopf 4y ago
I love seeing this hit HN every so often. It reminds me of just how hilarious us humans introduce complexity just everywhere.
dgb23 4y ago
Nikita Prokopov is right. Performance matters. - It is a major part both UX and the utility of a program. The success of the iPhone is often attributed to design, but it was also really responsive, fast and simple in comparison to other smartphones. - We tend to do stuff to "fix" performance on top of things that make the whole system much more complicated and brittle. Caching is the best example here. Caching proliferates and adds complexity to every layer. Another one is adding more machines. Same story. - Programmer time is valuable. But how about reducing the complexity of a system and make it reasonably fast? Less failure modes means less worry and work. Fast feedback loops are absolutely _essential_ to keep a programmer in a productive flow. - It costs less. See the two points above. - It is enabling. There are things you don't even consider doing because everything is slow. You don't have enough currency in the form of time and cycles to do more. - It is not that hard. As described in the article, it is often just a matter of throwing stuff away that isn't needed. Start with less abstractions and "flexibility". Build something reasonable that cares somewhat about performance and you probably get orders of magnitude faster results. What hinders us? People introduced the joke of "just wait a year or two and it's faster" because hardware kept fixing bad performance. This is over. We're drowning fast hardware with slow software, quicker than hardware can keep up. Also many of the improvements are on the level of parallelization and caching. Programs need to be aware of that at some level. There is the famous quote "premature optimization is the root of all evil". I'm not talking about optimization here. I don't even know how to do optimization outside of trivial things. What I'm talking about is just removing or avoiding unnecessary cruft, and very basic efficiency. Overhead is not taken seriously. When I read comments like "IO performance dominates web apps" then I wonder if they have ever run a profiler. Do you really need to make that many db calls? Have you designed your data model with respect to access patterns at all, or did you follow some "Best Practices" modelling which is disjoint from what your app is doing? Is all that indirection necessary for you to write maintainable, concise code? Adding unnecessary cruft is endemic in web development and seems to be part of our culture. We're very much concerned with short term productivity and everything keeps changing quite fast. Part of this is businesses decision makers wanting to think of developers as interchangeable and development as a commodity. I disagree. I think there is a niche for web agencies that make simple, robust and performant things.
eulenteufel 4y ago
Finally a website that gets dark mode right! ;D
Arwill 4y ago
I am a big fan of single header libraries. And libraries that i not just link to, but which i am allowed to reuse and compile myself. Then i gut that library and remove everything i don't need. Less code, less space, less runtime and less potential bugs hopefully. For example there is a single header library HTML renderer and its fast, but does not run JavaScript. And there is for example Chromium, which is the complete browser experience, but its 10GB source code, no sense in trying simplifying any of that.
- _gabe_ 4y ago
  > For example there is a single header library HTML renderer and its fast, but does not run JavaScript. What library is this and does it support CSS? I'm using RML UI right now, and I'm pretty happy with it but it's pretty bloated imo. I'd love to switch if I could :)
  - Arwill 4y ago
    Its technically not a single header, but almost. I was thinking about litehtml. Specifically this recipe: https://twitter.com/ocornut/status/890210588600565762 https://twitter.com/ocornut/status/890210588600565762 I am already using ImGUI, and its a bonus if i don't have to include another font engine.
jerDev 4y ago
Interesting article. I have thought a lot about this frustration on the job. However, I’m on the opposite side of the fence. In summary, there are two fundamental ideas in software engineering that people constantly grapple with especially new grads: 1) If it works, it’s not broken. Or 2) It’s broken until it’s not. ( also can be seen as “right” vs. “right now” ) Let me explain further; - first point refers to the idea that if the constraints provided are achieved, there are no tasks to be done. - second point refers to the idea that there is a correct way to do something. I’m not going to take long, but i strongly stand in the first camp. There is no value in building kingdoms in details that aren’t required. Could we have it run in 010ms vs 250ms? Could we make this look better? Could we do this in a different way? Etc. none of this matters if it works. Now; you might ask the following questions: - what about scalability? What if I’ve done this before and I know pitfalls of xyz? And my answer is, politely, iterative improvements after a working model if those improvements become necessary. Those improvements are not defacto necessary. And when I say necessary, I mean customers are returning the product, not an engineer can’t sleep at night because of his/her neurosis. In summary, the world you live in was at-best designed with an acceptable tolerance for error. I call that, “good enough”. There is no other measure than “good enough” when it comes to acceptance criteria of anything.
- leeoniya 4y ago
  > Could we have it run in 010ms vs 250ms? if it runs once per hour, then it may be inconsequential; if it runs every 30s, then it might be an extra 1hr of battery life for your phone, but people will still keep using it and not complain. is there a problem? maybe.
  - thesz 4y ago
    30s is a 120 times per hour. Or, 30 sec of difference per hour between 250ms and 0 ms (instanteneous). To get a hour of difference my phone needs to have battery life of 120 hours. For more reasonable 10 hours of battery life I will get about 5 minutes saved. I see why no one will complain about that difference.
    - 4y ago
29athrowaway 4y ago
In fictional universe of FF VI, there are magical creatures with magical abilities called espers. What is interesting in this game, is that the evil faction in the game are not the espers, but humans that figured out how to enslave them, extract their life essence and turn it into power. The empire does not care about the well-being of espers or their personality, they only care about their abilities. There is a part of the game where you see all the espers in a scientific facility, being drained of their abilities and life, and then thrown into a dumpster when they have no magical power left. That is the software industry. The good faction are humans that decide to fight the empire, and discover that espers can voluntarily give their power to humans in a more effective way than what the empire can forcefully extract from espers. They use that power to defeat the empire. Those guys are open source projects.
- cs137 4y ago
  I used to refer to turning 35, as a programmer, as "being turned into magicite". I'm almost 40 and I'm better than ever, but I doubt I'd get hired for a corporate programming job at this point, not that I'd want one. Have you played the Brave New World mod?
  - 29athrowaway 4y ago
    I have not played it but I have seen people playing it on Twitch.
- skolskoly 4y ago
  Clearly the software industry is more evil than the FF villains though. Wasted computers are not alive, and yet they WANT them to be sentient.
cs137 4y ago
A big part of the problem is that the web is full of parasitic mechanics. Javascript is shit, both the language itself and most of the code written in it, but the person who suffers from shitty Javascript is... you. It runs on your computer--that's the parasitic part--and not that of the entity serving it. So they don't care. Until ad dollars stop coming in, it doesn't matter. Businesses generally think they can scale up with shitty code and inexperienced engineers and "do quality" later. Can they? Well, enough of them can that billion-dollar companies exist. I'm very skeptical that capitalism's signals indicate anything about true value (moral, creative, or otherwise) but the fact is that the "start cheap 'n' shitty" approach works, and it has worked for a long time. (Low quality software has been an issue for my entire adult life, and by HN standards I'm an elder dragon legend.) So long as it keeps working, it won't die. Markets don't punish what is bad; markets punish what is unfit by the definition set by the market. What's funny to me today is that people tend to underestimate how fast computers are--or can be. Adding a million numbers? You can do that in a fraction of a second. People are so used to the crapware that capitalism produces that we've accepted these ridiculous delays, not for any good reason.
IYasha 4y ago
Dear Nikita, you have my signature under (almost) every your word. ) You describe the reason I've became disgusted with programming and IT trends in general and quit being a programmer.
buchoo 4y ago
Parkinson's law in software is real. As Jon Blow often says, our computers are basically supercomputers that are astoundingly bogged down by bad software development practices. The computer I'm on is at the very least several dozen times more powerful than the one I had 20 years ago, yet a lot of functionally equivalent software probably runs at about the same speed, certainly not an order of magnitude faster let alone several dozen times faster despite not doing several times more. The problem is that a lot of software developers don't even realize how bad their software design is because of prevailing norms, and the state of affairs can only be upended by certain developers showing that another way is possible when programming with the hardware rather than against it. As someone who has to use Visual Studio and ReSharper professionally, I was absolutely blown away when I tried out the (still in alpha) 10x Editor and found it accomplishing in less than a second something that takes ReSharper several dozen seconds, during which it locks up the editor, or that it might even fail to do entirely, having succeeded only in making VS unresponsive (finding all usages of a widely overridden virtual function): https://www.10xeditor.com/ https://www.10xeditor.com/ (Disclaimer: I was impressed enough by the editor's performance to become a paid supporter.) (Another VS extension I use is P4VS, which is slow, buggy garbage that will lock up VS if you look at it funny. In fact, P4V and the P4 extension for Windows Explorer are also utterly dismal, but Helix Force just don't seem to give a damn.) Another example is Casey Muratori making a terminal several orders of magnitude faster than the Windows one simply by designing it well, without even going through an optimization process: https://youtu.be/hxM8QmyZXtg https://youtu.be/hxM8QmyZXtg It's fair to say that a huge amount of modern software is at least an order of magnitude slower than it needs to be. The standards in the software development industry are frustratingly low and there is a deplorable dearth of disruptors to push them in another direction.
tenebrisalietum 4y ago
One of the things this article talks about is web sites being unable to animate things close to 60Hz and wondering how that will go when 120Hz and higher displays become mainstream. However: Doing everything over a worldwide internetwork on a CPU and OS independent platform that can be used for tasks as diverse as talking to your GPU, or interacting with real time audio/video was not part of the "original plan." Yes, DOS is more responsive but you can't have 6 image-heavy large documents open on your computer while Webex'ing, observing your weather, having a Youtube video open, and playing a game all during your Webex under DOS. The comparison is not apples to apples anymore, but if DOS serves your needs, use it. It reminds me of this article comparing Windows NT to CPM: http://www.oualline.com/practical.programmer/cpm.html http://www.oualline.com/practical.programmer/cpm.html The article also talks about Windows updates. That's a legitimate concern. Microsoft needs to rip out that system and start completely over. Look at this article from Microsoft entitled "Windows Updates using forward and reverse differentials" (https://docs.microsoft.com/en-us/windows/deployment/update/psfxwhitepaper https://docs.microsoft.com/en-us/windows/deployment/update/p...) - wtf? I don't even know why any of this is necessary for a system that should just overwrite files with later versions. If you wanted evidence that Windows Updates is overengineered, there you go.
otter-rock 4y ago
I used to feel this frustration until I accepted that the economics of software usually lead to different requirements. People are making rational choices, so no amount of attitude or culture change will make a significant difference. Different requirements can be found in different industries, or different fields all together.
dasil003 4y ago
I get the frustration, but I think this is just the cost of the incredible volume of software that we have. As software engineers we pride ourselves on our systemic thinking, so it's tempting to look at the situation and say "we can and should do better". But it's an illusion to think of software ecosystems as being designed. The reality is individuals, teams and even huge companies are constrained by ecosystems which are too big to really control and optimize in a systemic fashion. Useful software today beats perfect software tomorrow. That's why software is not well-optimized: because less optimized software beat it to market at multiple layers of the stack. That's why web apps slowly killed native apps: because shipping binaries to multiple platforms is way harder than loading a URL in a browser (or thin wrapper thereof). One thing I've learned the hard way in life is to focus on what one can control. We may not like the tradeoffs others have made and the systemic outcomes they led to, but we can't control them. A better tactic is to pick one very specific area you think you can make a dent and focus on that.
- routerl 4y ago
  > A better tactic is to pick one very specific area you think you can make a dent and focus on that. Amen. Best practices taught me "don't break extra windows, and repair broken ones as you find them", but I'm finally at a point in my career where I can say, with confidence, that some broken windows aren't worth fixing; you might have enough expertise to know that it should be fixed, while simultaneously lacking the expertise to do so in a cost-effective way. Case in point: in the iOS app I'm currently working on for a client, my team discovered a bug that was, very clearly, an interest payment on the technical debt the client has been accruing. The "correct" bug fix would entail rewriting a lot of existing functionality (i.e. paying down a big chunk of the principal, on the technical debt). This was not cost effective for us, since we were being paid to fix the bug as written. So we fixed the bug, while introducing functionality that could, in the future, be used to pay down the tech debt principal, should the client desire to do so. Spoilers: the client will never desire to do so, and therefore we've actually just added cruft to the codebase. But this conclusion is not allowed, in the client-provider relationship; the bug is fixed, therefore contract conditions have been met, therefore the work is done. The cause of bad software is, simply, that the incentive structures and scheduling required for making good software don't usually exist.
thewebcount 4y ago
I don’t disagree with the sentiment of the article. But it really does seem to be dependent on the type of work you’re doing. In 2000, I started writing plugins for Final Cut Pro. You could write “real time” plugins for it! That meant you were working in YCbCr 4:2:2 at 320x240 and 30 frames per second (so quarter-sized frame, with 2/3rds the data that an RGB frame would carry and half as often). 22 years later, I’m still writing such plugins, but on the top-end systems you get multiple streams of 8K uncompressed RGB video at 60fps and you can play back in real time. Some things really have gotten significantly faster. But yeah, using a web browser to do normal tasks like display emails is insanity and very very wasteful.
rileymat2 4y ago
> Windows 95 was 30MB. Today we have web pages heavier than that! Windows 10 is 4GB, which is 133 times as big. But is it 133 times as superior? This is an interesting question, I am not sure how I would measure this. Stability/Uptime is probably 100x better than I recall for my windows 95 machine. They have done a ton of important security work since 95, from UAC to process isolation. Would I pay 100x more? I am paying less now.
capableweb 4y ago
Previous threads, with lots of discussions: - 317 points | Sept 18, 2018 | 96 comments | https://news.ycombinator.com/item?id=18012334 https://news.ycombinator.com/item?id=18012334 - 934 points | Jan 1, 2020 | 498 comments | https://news.ycombinator.com/item?id=21929709 https://news.ycombinator.com/item?id=21929709
- dang 4y ago
  Thanks! Macroexpanded: Software Disenchantment (2018) - https://news.ycombinator.com/item?id=27775262 https://news.ycombinator.com/item?id=27775262 - July 2021 (1 comment) Software Disenchantment - https://news.ycombinator.com/item?id=27041180 https://news.ycombinator.com/item?id=27041180 - May 2021 (4 comments) Software Disenchantment (2018) - https://news.ycombinator.com/item?id=21929709 https://news.ycombinator.com/item?id=21929709 - Jan 2020 (488 comments) Software disenchantment - https://news.ycombinator.com/item?id=18012334 https://news.ycombinator.com/item?id=18012334 - Sept 2018 (94 comments) Software Disenchantment - https://news.ycombinator.com/item?id=17996272 https://news.ycombinator.com/item?id=17996272 - Sept 2018 (1 comment)
azanar 4y ago
We could perhaps get better software, but at what cost? One of the nice things about engineering disciplines is that costs can be reasonably forecast. There are spectacular counterexamples (e.g. Big Dig), but bear in mind those projects were much more than "just" engineering projects. Software costs seem hard to forecast. Software integrates with other software. Software is created via a whole pantheon of algorithms. The "better" algorithm is often context dependent. That context depends on what else gets integrated. Did I mention we probably won't know at the design phase how things will be integrated? Other engineering disciplines integrate with things that are well-known: the ground, water flows, the atmosphere. These things don't change. This is nice. This article makes it sound like "better" is just a matter of spending more. My read is different: spend more and be correct. Correctness _isn't_ just something we know but aren't allowed to implement. In many cases, we don't _know_ what correct is. We have to _find_ correct via exploration and experimentation. Even when we do, we might severely misjudge the effort required to get there. This complexity isn't just accidental. The world is a complex place. Our human minds act on a small portion of that complexity, based on all sorts of heuristics we aren't even conscious of. They work most of the time. The rest of the time? We're compelled to shoehorn things into our heuristics. This ends increasingly poorly the more complex the underlying mechanism is. This is a hard argument to make to someone who will not accept that they are not correct. Correct in their criticism. Correct in their diagnosis. Correct in the the behaviors that lead to our condition. Correct in asserting that avoiding those behaviors would result in no unanticipated consequences. Resentful about it because they were correct, and we didn't accept that.
oldjavacoder 4y ago
"We put virtual machines inside Linux, and then we put Docker inside virtual machines..." Hold my beer.
RivieraKid 4y ago
An observation I had while working in IT is that programming involves a lot of detail which is hard or impossible to notice from the outside (project managers, testers, users). And the average programmer is quite bad and doesn't have a perfectionist mindset. For example, let's say someone writes code which reads and parses 1 MB JSON file on every keystroke. From the outside, this is usually undetectable. Whenever someone makes something 10% slower or larger, adds a non-obvious error or implements a feature with 10x more complexity than possible, it's often barely distinguishable from a much higher-quality implementation.
garrisonj 4y ago
I would switch music streaming services for a client that wasn’t buggy. I think there is an untapped market for a software company that provides high-quality software. Market competition might kick in if a company can pull it off. It's probably more complicated than it sounds, though, because software frameworks don't provide that level of quality.
narag 4y ago
There's a couple of points in the article that I don't see discussed here. One is the comparison with games. So the article is about other categories of software. Has someone thought of other kind of "gamification"? I sometimes think that I'd love to see some fancy gaming interfaces outside games. The other is that, forget about solutions, frustration is a very powerful force and it has consequences. Frustration for the users and also frustration for programmers. This used to be a job considered interesting and fulfilling.
z3t4 4y ago
All software is shit, the more you have the bigger the pile. So if you want to write a fast and bug free program, make the scope as small as possible.
dinvlad 4y ago
"Back in the days" I used to think 256KB of RAM on a modified Speccy was already plenty, and dreamt about getting one of those 256MB(!) PCs, which would open a _universe_ of opportunities. Heh, that was so naive - not because of it being possible in principle, but mostly because of all the bloat described in this article, plus misaligned business incentives. These days, writing any software that would fit within mere dozens of KBs like the famous .kkrieger (an entire better-than-original-Doom-looking FPS game!), seems almost out of reach. Although it's motivational to dream once again through projects like Redbean that everyone is posting about. But at the same time, I feel like unless you've lived through those times, it's sort of a "lost art" and is only appreciated by a vast minority these days. In other words, the whole idea of minimalism in software is not even thought about as something that existed/could exist (you can't imagine a yellow Jeep if you've never even heard of a Jeep..)
galaxyLogic 4y ago
It's bit like "shrinkflation" where you get less for the same cost because that reduces producers' expenses. In software we get the same functionality as 20 years before on similarly priced hardware. But we don't get the speed-benefits we could and should expect. This may be because software producers prefer making things easy for themselves by using ever larger libraries. It reduces their costs but makes software slower?
z3t4 4y ago
> Linux kills random processes by design Linux will only kill processes if there are no swap left. So always have swap. You can also configure what Linux should do when there are no memory left.
trinovantes 4y ago
Be careful making your software too quick or else your client might think something is broken
cageface 4y ago
Analogies comparing software to most other forms of engineering are not usually very helpful. The considerations and constraints that inform automobile design are totally different than those of a typical mobile app or CRUD web shop. We know how to build software that’s efficient and reliable. It’s a slow and expensive process. If anything discourages me about software engineering it’s that so many of us don’t seem to be able understand that the nature of our discipline is different.
bmitc 4y ago
This rings true and frustrates me as well. My entire career I get bogged down with being so disappointed with the tools that we use in the software industry, that it totally distracts from building new things. Perhaps it is my mathematics background that spoiled me. In mathematics, you rarely are concerned with the tools that you have at your disposal. In most cases, they have been designed well, iterated on, smoothed out, etc., and above all, they just work. Aside from the most advanced, cutting-edge work, this is generally true. Of course, there's always work on foundations, different paradigms of mathematics, and more, but I think the point is clear. Maybe an even clearer point is imagining a carpenter who has to rebuild his hammer every day because it stops working, and then imagine that the instructions to build a hammer are practically undocumented scribblings on some napkins. In software, and actually in engineering as a whole, there is a large percentage of work that goes into solving problems created by other engineers. This isn't all the work, of course, but it is a depressingly large amount. In general, I am less concerned about all the constraints of software artifacts, e.g., size, slowness, etc. While those are a drag and can be frustrating, I am more concerned with two things: software that works and software tools. The tools that we use in this industry are nothing but antiquated. Software engineers equate programming to text, and thus, all the tooling revolves around text. Most so-called IDEs are simply advanced text editors. Tools like Git are beloved, and in Linus' own words, I'm surprised they made it to adulthood. Even in a text-based language, I absolutely do not care about lines that changed. I care about semantic things, like functions, modules, expression blocks, etc. I want my source-code control and comparison tools to tell me what actually changed and not what characters of changes are present. I could go on and on this topic. And part of the consequences of poor tools, we have software that works poorly and is just balls of mud stacked on top of more balls of mud that have dried out they're brittle to even touch. But that's just one component of why software doesn't work. The other is how we think about software. Thinking about software as just a thing that a person tells a computer to do is not enough. Software is about three things: (1) computation, (2) communication between humans and not between human and machine, and (3) how to think about things or encode a domain with software. We suck enough as it is with (1), but (2) and (3) are basically ignored at large. Almost all engineering problems in deployed systems relate down to communication issues and poor understanding of the domain at hand. But not only does everyone concentrate on (1), they concentrate on very narrow aspects of (1). It's almost no surprise that things are as bad as they are in software.
EdwardDiego 4y ago
On the plus sides: * I haven't had to specify IRQ or DMA to listen to music in a long time. * I plug stuff into my USB / thunderbolt ports, and _it just works_, even though I'm running Linux * I can play games on Linux, real actual commercial ones, not just ones involving Tux the penguin * I can send my Mum videos and she can watch them without worrying about codecs, without me having to explain what a codec is. Software is awesome these days. Could we do better? Always, was it better in the "good ol days"? Hell no.
gyamet 4y ago
Not all software is crap. I've had my game server for a popular multiplayer online web game running continuously for over two years now. Same Linux process, same cloud VM. Never crashed, never needed to reboot. Node 12, everything done in TypeScript, from the network protocol to the physics engine. All it took was careful design and development. Not that difficult if you put your mind to it and don't cut corners.
amtamt 4y ago
Read on another link... Voyager had 67kB RAM in it's computers and has reached the end of solar system. We really need to rethink system design and implementation.
- 0x69420 4y ago
  a good general-purpose multilingual text and graphics layout engine does in fact turn out to be a computationally harder problem than reaching the end of the solar system, sorry
kvark 4y ago
One of the signs of an apocalypse/bloat is latency. Watching the industry from the intel 386 era, I’m only seeing it increasing. Every little action takes longer to start. It feels like we (in a larger sense) focused too much on throughput:) The perfect latency device I held was Nintendo DS.
FridayoLeary 4y ago
I am immediately reminded of this saying: "Anyone can build a bridge that stands, but it takes an engineer to build a bridge that barely stands". I guess Nikitionsky wants to apply the same standards to software engineering.
robocat 4y ago
Agree with the gist, but some of the examples are so poorly informed that the whole article is tainted. > Google’s keyboard app routinely eats 150 MB. Is an app that draws 30 keys on a screen really five times more complex than the whole Windows 95? Calling it 30 keys is silly, and undermines their argument because it certainly isn’t 30 keys. How many MB is reasonable for features I use like the swipe feature? For Chinese entry? For spelling support? > Google Play Services, which I do not use (I don’t buy books, music or videos there)—300 MB that just sit there and which I’m unable to delete. The writer is showing their absolute ignorance of what Google Play Services does - a better name would be Android System Services. Maybe question the need for 300MB, but use some intelligence rather than just making crappy off-the-cuff strawman arguments.
- rozhok 4y ago
  So what exactly does google keyboard and google play services? Why it consumes so much space? REAPER (http://reaper.fm/download.php http://reaper.fm/download.php), the full-fledged complex desktop application (DAW) weights only 15MB.
chadcmulligan 4y ago
Isn't this a web developers lament? Look at native code or the wonderful world of 3d graphics, speed is piling on. But look at web development with the layers of frameworks to display a text box. The solution seems fairly obvious I would have thought.
- int_19h 4y ago
  No, it's also a lament of every desktop user & dev, because we get more and more web apps repackaged in Electron, with all that entails perf-wise.
EVa5I7bHFq9mnYK 4y ago
It took me 20 seconds to compile and link a program on my PDP 11 with 64k of memory (yes, 64k for the OS plus all the drivers plus user programs). It still takes me around 20 seconds today with 1,000,000 times more memory and ~10000 times faster processors.
fungiblecog 4y ago
the irony of this is that we have all the bloat but we also have to live with decisions that were only made because of the limitations of the past. I'm referring to things like arbitrary limits on filename lengths. And worst of all databases that think it's a good idea to make you delete information by default to "update" it rather than keeping all the changes. Disasterous.
1vuio0pswjnm7 4y ago
"That is not engineering." It does not stop the folks that do it from calling themselves "engineers". When faced with the potential for being regulated, large "tech" companies that lobby regulators claim they can regulate themselves. "Tech" companies also believe they can redefine what is "engineering" and hire "engineers" who have no corresponding certifications. In some cases, the companies themselves are the certification providers. History has shown that self-regulation does not work. Nor do blog posts complaining about declining software quality.
hsn915 4y ago
There are many ways to be disgruntled by this, but IMO you should instead think of it as an opportunity. If the world was full of well behaving well designed software, it would be difficult to find useful things to contribute. Since the world is full of bad software written by, well, other programmers, this is just a chance for you. Take it. Quit your job and do something useful.

230 points by ShowalkKama 4y ago

> So it’s our mission as engineers to show the world what’s possible with today’s computers in terms of performance, reliability, quality, usability. If we care, people will learn. And there’s nobody but us to show them that it’s very much possible. If only we care. Software engineers by and large care and yet we can't even get the businesses we work for to care, the stakeholders that performance would matter to arguably the most. I think the average person is even more apathetic about a topic like optimizing app performance.

tsss 4y ago
I have made very different experiences. The programmers don't care either. They just want to pump out features, no maintenance, no documentation, no long-term improvements.
- cs137 4y ago
  That's not what the programmers want. It's how they're incentivized. If you have to meet your "they're not deadlines but, really, they are" sprint targets, then what can you do but minimally complete the tickets assigned to you and hope not to step on anyone's toes? It doesn't help that good programmers get flushed out of the industry due to conscience and age, only to be replaced with cheap, shitty ones.
  - tsss 4y ago
    No, in my case that's really what they want. I think our project management would totally give us the time to improve something, if we can argue that it's needed. It's really one or two developers who block everything that isn't the absolute minimum possible amount of work or their own pet idea.
    - mgkimsal 4y ago
      > I think our project management would totally give us the time to improve something, if we can argue that it's needed. You shouldn't have to argue for it. It's something "project management" should care about as a top-level concern, scheduling time for it. Stability, documentation, tests, performance, security - these are all "features" just as much as "make a button dump a CSV for a user".
      - tsss 4y ago
        I mean, they do to the extent that they can. We have a story template that specifically mentions performance, monitoring, security and documentation requirements. We also have weekly meetings to discuss technical issues and a dedicated backlog where devs are supposed to put purely technical stories, but it is usually empty. When the prevaling philosophy of the dev team (or its most vocal members) is "'good enough' is good enough", then there's not much the project management can do short of forcing a minimum amount of maintenance tasks. Of course, project management is also happy if they have more capacity for feature stories, so the impulse has to come from the dev team.
      - tacitusarc 4y ago
        Often (good) PMs assume that those tasked with making technical decisions implicitly understand all the listed concerns are, in fact, requirements. They are then surprised when the engineers explain they didn’t prioritize those things when doing the work.
- ratww 4y ago
  I also share your experience. Never saw management or PO complaining about developers taking time to optimise. I actually never even saw an experienced developer taking an inordinate time to optimise something. It's always refactoring and rewriting that takes too much time (and often causes performance regressions). Developers however are quick to point that optimisation is "not in the interest of the business", as can be seen in this very topic, or that something is "good enough" since a lot of people are using.
- spaetzleesser 4y ago
  "The programmers don't care either. They just want to pump out features, no maintenance, no documentation, no long-term improvements." That's how people are taught. In most companies nobody cares about quality. getting stuff out quickly is where the money is. Slow, deliberate work doesn't pay.

brunojppb 4y ago

I did the Portuguese translation of this article for Nikita back then and it’s interesting to read this article again in 2022. While things are still bloated, I am very hopeful for the future after seeing many cross-platform initiatives written in Go and Rust. I hope to read this article again in 2026 and see faster, less resource-consuming apps running on our machines.

jackosdev 4y ago
Yeah there has been some great efficient software coming from the Rust and Go communities, ripgrep, nushell, lazygit, helix to name a few I use everyday

bbbobbb 4y ago

The text resonates with me but there isn't much practical advice. What should I do as a normal developer working on normal business products? I try not to do obviously slow and stupid stuff but it is not the main focus. It does mention it but just to reiterate: The business value of getting things out is larger than getting things right most of the time. The architecture are bloated micro-services, the infrastructure is overcomplicated, the response times are order of magnitude longer than they ought to be. But there is no time to care. The next shiny feature or integration or whole business case is waiting to be implemented and shipped. We cannot afford to spend time on improving things people don't complain about over things that bring more money. I guess that is where the disenchantment part comes in. Most companies are not in business of engineering stuff well if that is not what makes them money.

nine_k 4y ago
Developer's time is much more expensive than CPU's. So much more CPU's time is spent ("wasted") to save some amount of developer's time. This includes developer's s study time, that is, hiring less educated and experienced developers. In 1990s we had a similar effect: the CPU performance and RAM sizes grew so rapidly that "poorly written" and "bloated" software became "butter-smooth" and "lightweight" in a couple of years. Now we have the cloud instead, when spinning a dozen more instances or upgrading to a slightly more expensive plan gives the performance boost that solves many bottlenecks (much) cheaper than paying a team of 3 developers to spend 6 extra months to do things right. The endless CPU growth gravy train stopped in mid-2000s. I wonder when the endless cloud scaling train will slow down materially.
- bbbobbb 4y ago
  It's not just dev time vs cpu time. The thing the article mentions and what I was trying to echo is that software is slow and overcomplicated despite that. It would be unusable without fast hardware. But people are used to programs being slow and bloated. People and companies are rarely willing to pay premium for efficient programs. So here we are, gluing stuff together so that we're fast to market with every next feature while collectively wasting lifetimes as our apps load and perform basic actions. I am not even saying it's wrong. There are plenty of things I'd rather have now and slow than later/never and fast. Nor I am saying given the time I'm capable of making all our software significantly leaner and faster. I am just echoing the disenchantment and some frustrations.

sp332 4y ago

That sync conflict window doesn't force you to lose data. Just check both boxes and you keep both copies. And the python situation was really bad, but things have improved a lot in the last 4 years.

ptx 4y ago
The confusion is understandable since the UI designer made the checkboxes look like radio buttons.

phkahler 4y ago

Ironic that I was offered a simplified version of the article to read...

mrob 4y ago

Meanwhile, I'm using a 13 year old desktop running Debian Unstable and it feels even faster than when it was new. It's subjectively faster than an M1 Mac Mini, despite the Mac beating it in benchmarks. I attribute this to two main causes: ruthlessly deleting/disabling everything I consider bloat (e.g. animations, text anti-aliasing, gradient fills, rounded corners, transparency, compositing, Javascript, anything wireless etc.), and using a low-latency gaming keyboard/mouse/monitor. Performance is available if you want it. But I think most people prefer aesthetics.

jolux 4y ago
I find text a lot harder to read without anti-aliasing.
- mrob 4y ago
  To be honest, I doubt disabling anti-aliasing makes any perceptible performance difference itself (although it gives me sharp text without needing 4K, which probably does). But your comment shows the important of customization. I disabled things I personally considered bloat. Other people will consider different things to be bloat. Software should give you that freedom (and Free Software gives you the ultimate freedom to customize).
  - password4321 4y ago
    "Ain't nobody got time for that!" Actually, I would be interested to learn how much time you've invested in customization, especially if there were points when the system became temporarily unusable.
    - mrob 4y ago
      Almost certainly more time than the customizations have saved me. I still consider it worth doing, because I enjoy doing it, and it makes the computer more pleasant to use. I have made the computer temporarily unusable several times, but I have an old netbook too, so I'm never stuck without a usable computer while I fix it.

hermitcrab 4y ago

The old engineering adage is: cheap, fast, reliable - pick 2. Or maybe < 2 with software. And the end of the day most people don't want to pay what development of fast and reliable software costs and businesses know that. So we end up with the shoddy bloatware that are prepared to pay for. If you don't like that, start your own business and write software that meets your standards. If you are too purist, you might find it a struggle to survive financially up against less scrupulous competitors.

bob1029 4y ago

It would seem this is all just a matter of constraints and objectives. It's not that we are unwilling or unable to make things faster. For instance, when presented with the task of porting Quake to the GBA, we somehow find the means to make this happen, despite the underlying CPU only operating at 16.78 MHz. Playable frames per second are achievable on that system. Scaling "GBA Quake"-levels of optimization up, you could probably run thousands of simultaneous clients off a single AMD system today - regardless of GPU capabilities. But, I don't think the market is demanding that kind of experience anymore, especially not at that kind of scale. The point I would like to make: High quality experiences only seem to manifest when enough adversarial pressure has been applied at design/architecture time. This is not just limited to software.

rektide 4y ago

Focusing on the little unpleasantnesses distracts from seeing a bigger picture. The net software experience hasnt changed or improved much. There's a lot of fine tuning & apps getting tweaked, but the platform of computing- to users- has been locked at the same fixed boring low-power level for well over a decade. If you want to be disenchanted, do it from a macro perspective.

DeathArrow 4y ago

I think the biggest wave of the bloat started when SPAs became a thing. After that, fronted web developers thought they can write mobile and desktop apps, so the bloat reached mobile and desktops, backed by repurposed web technologies.

dgb23 4y ago
There are plenty of desktop apps that are bloated and slow and plenty of web based apps that are fast and light. Thinking of Figma (web based) vs Adobe XD. The former "installs" much quicker, does cooler things, is more useful, more responsive. The solution to the problems mentioned in the article is not "use technology X", it is about shifting focus on quality.
intothemild 4y ago
I tend to agree here. I don't blame SPAs (not that i think you are), but it does feel like there is correlation between SPAs rise in usage and with the frontend becoming worse. Not that it's the tool, but the welder of the tool. I'll explain, I think that basically a lot of frontend engineers started using SPAs for too many different usages... Like using a SPA instead of a static page for a really simple basic website.. to me this is like when a meeting could have been an email. Or adding in so much tooling to their site which doesn't really solve any problems except make new problems, so now there's more tooling for that. (read state management, client side routers) I remember at a <very popular SPA> conf I spoke to the two guys who made a very popular framework for building that popular SPA, they asked me how my serverside project used express.js's router... Like the questions they had were along the lines of "how can you do (insert basic routing thing here) in express?". The only exposure to express they had was a catch all route to their apps main clientside router. I was stunned... They were aware there was this tool, and ignored it.. instead deciding that they could do better. To me this was post SPA frontend in a nutshell.
- ChadNauseam 4y ago
  You acknowledge that it's the wielder of the tool, but I feel a need to repreent the SPA evangelism strike force because they're just so freaking cool. The web is a UI framework with features that are actually pretty hard to find elsewhere. It has native support for: tabs, forward and backward, zoom, and coolest of all, links so you can send the current UI view of an application to someone who's never heard of it before and they can open it up in seconds. All of those apply to regular websites too, but SPAs allow you to write actual apps in a way that doesn't want to make you pull your hair out. And it's often possible for a well-designed SPA is indistinguishable from a native site. I maintain my personal website as a SPA. When I posted a monad tutorial on my site [0] to HN, not one person complained that my site is slow (it isn't) or that it doesn't work with JS disabled (it does [1]). Plus, when you hover over a link, it uses some SPA magic to prefetch the page you're going to visit, so the transition is even faster than it would be on a typical site. This is the archetypical case of "using a SPA instead of a static page for a really simple basic website" and I think it works really really well. There's definitely some room for improvement. I'd love to be able to make it a bit smaller by rewriting it in Rust through WebAssembly, but it's not quite there yet. [0]: https://news.ycombinator.com/item?id=30762281 https://news.ycombinator.com/item?id=30762281 [1]: except on pages that can't be implemented without JS, like https://chadnauseam.com/reasoning-quiz/ https://chadnauseam.com/reasoning-quiz/ or https://chadnauseam.com/productivity/rational-breaks/ https://chadnauseam.com/productivity/rational-breaks/

Ygg2 4y ago

> On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. A 3D game can fill the whole screen with hundreds of thousands (!!!) Yeah. Just update a tiny rectangle. And check Unicode validity. And render the Unicode character And re-do highlight. And spawn a box with autocomplete. Or not. And run the AST analysis. And depending on language check if there is an extension dealing with it. List goes on. I dislike the simplification that the article glosses over. Games are fast because they do one or few things that GPUs are great at. Text editors aren't as fast because they do a bunch of things that aren't as easily ported to a GPU.

anonymoushn 4y ago
Unicode validation runs at gigabytes per second. Text rendering is a tiny, tiny subset of game rendering. Not sure about highlighting, sounds like a mix of parsing and game rendering, so that's likely again to be one process that can run at gigabytes per second and another process that is a tiny subset of a process that often runs at 240Hz these days. Autocomplete, no clue, probably this could also be fast? You're like doing a lookup into an inverted index or a hash table or a range tree or something? So it takes like less than 3 microseconds to decide what the contents of the box should be? Oh, it doesn't, because you decided the way this should work is that several different processes should communicate with each other using JSON-RPC just to figure out what goes in the autocomplete box? Yeah, okay, sounds like a problem with the design then. Notably World of Warcraft does not send json over sockets between multiple local processes to decide how wide the nonempty part of each mob's health bar should be every single frame, and maybe one day we could try to figure out whether there's a reason for that.
- Ygg2 4y ago
  >Code validation runs at gigabytes per second. You sure about that? I remember UTF8 validation being a major source of slowdown when parsing XML in Rust. Branches kill CPU perf. And UTF8 has branch on every non ASCII char. Nvm. Those methods use SIMD tricks, which while neat are hard to generalize. Also not sure what JSON-RPC is referring to? LSP? Are you arguing that JSON is suboptimal? Like maybe, but it's close enough to rival binary formats. Plus you can parse GB/s of JSON. Even text editors that forgo LSP have speed issues, unrelated to JSON.

pknopf 4y ago

I love seeing this hit HN every so often. It reminds me of just how hilarious us humans introduce complexity just everywhere.

dgb23 4y ago

Nikita Prokopov is right. Performance matters. - It is a major part both UX and the utility of a program. The success of the iPhone is often attributed to design, but it was also really responsive, fast and simple in comparison to other smartphones. - We tend to do stuff to "fix" performance on top of things that make the whole system much more complicated and brittle. Caching is the best example here. Caching proliferates and adds complexity to every layer. Another one is adding more machines. Same story. - Programmer time is valuable. But how about reducing the complexity of a system and make it reasonably fast? Less failure modes means less worry and work. Fast feedback loops are absolutely _essential_ to keep a programmer in a productive flow. - It costs less. See the two points above. - It is enabling. There are things you don't even consider doing because everything is slow. You don't have enough currency in the form of time and cycles to do more. - It is not that hard. As described in the article, it is often just a matter of throwing stuff away that isn't needed. Start with less abstractions and "flexibility". Build something reasonable that cares somewhat about performance and you probably get orders of magnitude faster results. What hinders us? People introduced the joke of "just wait a year or two and it's faster" because hardware kept fixing bad performance. This is over. We're drowning fast hardware with slow software, quicker than hardware can keep up. Also many of the improvements are on the level of parallelization and caching. Programs need to be aware of that at some level. There is the famous quote "premature optimization is the root of all evil". I'm not talking about optimization here. I don't even know how to do optimization outside of trivial things. What I'm talking about is just removing or avoiding unnecessary cruft, and very basic efficiency. Overhead is not taken seriously. When I read comments like "IO performance dominates web apps" then I wonder if they have ever run a profiler. Do you really need to make that many db calls? Have you designed your data model with respect to access patterns at all, or did you follow some "Best Practices" modelling which is disjoint from what your app is doing? Is all that indirection necessary for you to write maintainable, concise code? Adding unnecessary cruft is endemic in web development and seems to be part of our culture. We're very much concerned with short term productivity and everything keeps changing quite fast. Part of this is businesses decision makers wanting to think of developers as interchangeable and development as a commodity. I disagree. I think there is a niche for web agencies that make simple, robust and performant things.

eulenteufel 4y ago

Finally a website that gets dark mode right! ;D

Arwill 4y ago

I am a big fan of single header libraries. And libraries that i not just link to, but which i am allowed to reuse and compile myself. Then i gut that library and remove everything i don't need. Less code, less space, less runtime and less potential bugs hopefully. For example there is a single header library HTML renderer and its fast, but does not run JavaScript. And there is for example Chromium, which is the complete browser experience, but its 10GB source code, no sense in trying simplifying any of that.

_gabe_ 4y ago
> For example there is a single header library HTML renderer and its fast, but does not run JavaScript. What library is this and does it support CSS? I'm using RML UI right now, and I'm pretty happy with it but it's pretty bloated imo. I'd love to switch if I could :)
- Arwill 4y ago
  Its technically not a single header, but almost. I was thinking about litehtml. Specifically this recipe: https://twitter.com/ocornut/status/890210588600565762 https://twitter.com/ocornut/status/890210588600565762 I am already using ImGUI, and its a bonus if i don't have to include another font engine.

jerDev 4y ago

Interesting article. I have thought a lot about this frustration on the job. However, I’m on the opposite side of the fence. In summary, there are two fundamental ideas in software engineering that people constantly grapple with especially new grads: 1) If it works, it’s not broken. Or 2) It’s broken until it’s not. ( also can be seen as “right” vs. “right now” ) Let me explain further; - first point refers to the idea that if the constraints provided are achieved, there are no tasks to be done. - second point refers to the idea that there is a correct way to do something. I’m not going to take long, but i strongly stand in the first camp. There is no value in building kingdoms in details that aren’t required. Could we have it run in 010ms vs 250ms? Could we make this look better? Could we do this in a different way? Etc. none of this matters if it works. Now; you might ask the following questions: - what about scalability? What if I’ve done this before and I know pitfalls of xyz? And my answer is, politely, iterative improvements after a working model if those improvements become necessary. Those improvements are not defacto necessary. And when I say necessary, I mean customers are returning the product, not an engineer can’t sleep at night because of his/her neurosis. In summary, the world you live in was at-best designed with an acceptable tolerance for error. I call that, “good enough”. There is no other measure than “good enough” when it comes to acceptance criteria of anything.

leeoniya 4y ago
> Could we have it run in 010ms vs 250ms? if it runs once per hour, then it may be inconsequential; if it runs every 30s, then it might be an extra 1hr of battery life for your phone, but people will still keep using it and not complain. is there a problem? maybe.
- thesz 4y ago
  30s is a 120 times per hour. Or, 30 sec of difference per hour between 250ms and 0 ms (instanteneous). To get a hour of difference my phone needs to have battery life of 120 hours. For more reasonable 10 hours of battery life I will get about 5 minutes saved. I see why no one will complain about that difference.
  - 4y ago

29athrowaway 4y ago

In fictional universe of FF VI, there are magical creatures with magical abilities called espers. What is interesting in this game, is that the evil faction in the game are not the espers, but humans that figured out how to enslave them, extract their life essence and turn it into power. The empire does not care about the well-being of espers or their personality, they only care about their abilities. There is a part of the game where you see all the espers in a scientific facility, being drained of their abilities and life, and then thrown into a dumpster when they have no magical power left. That is the software industry. The good faction are humans that decide to fight the empire, and discover that espers can voluntarily give their power to humans in a more effective way than what the empire can forcefully extract from espers. They use that power to defeat the empire. Those guys are open source projects.

cs137 4y ago
I used to refer to turning 35, as a programmer, as "being turned into magicite". I'm almost 40 and I'm better than ever, but I doubt I'd get hired for a corporate programming job at this point, not that I'd want one. Have you played the Brave New World mod?
- 29athrowaway 4y ago
  I have not played it but I have seen people playing it on Twitch.
skolskoly 4y ago
Clearly the software industry is more evil than the FF villains though. Wasted computers are not alive, and yet they WANT them to be sentient.

cs137 4y ago

A big part of the problem is that the web is full of parasitic mechanics. Javascript is shit, both the language itself and most of the code written in it, but the person who suffers from shitty Javascript is... you. It runs on your computer--that's the parasitic part--and not that of the entity serving it. So they don't care. Until ad dollars stop coming in, it doesn't matter. Businesses generally think they can scale up with shitty code and inexperienced engineers and "do quality" later. Can they? Well, enough of them can that billion-dollar companies exist. I'm very skeptical that capitalism's signals indicate anything about true value (moral, creative, or otherwise) but the fact is that the "start cheap 'n' shitty" approach works, and it has worked for a long time. (Low quality software has been an issue for my entire adult life, and by HN standards I'm an elder dragon legend.) So long as it keeps working, it won't die. Markets don't punish what is bad; markets punish what is unfit by the definition set by the market. What's funny to me today is that people tend to underestimate how fast computers are--or can be. Adding a million numbers? You can do that in a fraction of a second. People are so used to the crapware that capitalism produces that we've accepted these ridiculous delays, not for any good reason.

IYasha 4y ago

Dear Nikita, you have my signature under (almost) every your word. ) You describe the reason I've became disgusted with programming and IT trends in general and quit being a programmer.

buchoo 4y ago

Parkinson's law in software is real. As Jon Blow often says, our computers are basically supercomputers that are astoundingly bogged down by bad software development practices. The computer I'm on is at the very least several dozen times more powerful than the one I had 20 years ago, yet a lot of functionally equivalent software probably runs at about the same speed, certainly not an order of magnitude faster let alone several dozen times faster despite not doing several times more. The problem is that a lot of software developers don't even realize how bad their software design is because of prevailing norms, and the state of affairs can only be upended by certain developers showing that another way is possible when programming with the hardware rather than against it. As someone who has to use Visual Studio and ReSharper professionally, I was absolutely blown away when I tried out the (still in alpha) 10x Editor and found it accomplishing in less than a second something that takes ReSharper several dozen seconds, during which it locks up the editor, or that it might even fail to do entirely, having succeeded only in making VS unresponsive (finding all usages of a widely overridden virtual function): https://www.10xeditor.com/ https://www.10xeditor.com/ (Disclaimer: I was impressed enough by the editor's performance to become a paid supporter.) (Another VS extension I use is P4VS, which is slow, buggy garbage that will lock up VS if you look at it funny. In fact, P4V and the P4 extension for Windows Explorer are also utterly dismal, but Helix Force just don't seem to give a damn.) Another example is Casey Muratori making a terminal several orders of magnitude faster than the Windows one simply by designing it well, without even going through an optimization process: https://youtu.be/hxM8QmyZXtg https://youtu.be/hxM8QmyZXtg It's fair to say that a huge amount of modern software is at least an order of magnitude slower than it needs to be. The standards in the software development industry are frustratingly low and there is a deplorable dearth of disruptors to push them in another direction.

tenebrisalietum 4y ago

One of the things this article talks about is web sites being unable to animate things close to 60Hz and wondering how that will go when 120Hz and higher displays become mainstream. However: Doing everything over a worldwide internetwork on a CPU and OS independent platform that can be used for tasks as diverse as talking to your GPU, or interacting with real time audio/video was not part of the "original plan." Yes, DOS is more responsive but you can't have 6 image-heavy large documents open on your computer while Webex'ing, observing your weather, having a Youtube video open, and playing a game all during your Webex under DOS. The comparison is not apples to apples anymore, but if DOS serves your needs, use it. It reminds me of this article comparing Windows NT to CPM: http://www.oualline.com/practical.programmer/cpm.html http://www.oualline.com/practical.programmer/cpm.html The article also talks about Windows updates. That's a legitimate concern. Microsoft needs to rip out that system and start completely over. Look at this article from Microsoft entitled "Windows Updates using forward and reverse differentials" (https://docs.microsoft.com/en-us/windows/deployment/update/psfxwhitepaper https://docs.microsoft.com/en-us/windows/deployment/update/p...) - wtf? I don't even know why any of this is necessary for a system that should just overwrite files with later versions. If you wanted evidence that Windows Updates is overengineered, there you go.

otter-rock 4y ago

I used to feel this frustration until I accepted that the economics of software usually lead to different requirements. People are making rational choices, so no amount of attitude or culture change will make a significant difference. Different requirements can be found in different industries, or different fields all together.

dasil003 4y ago

I get the frustration, but I think this is just the cost of the incredible volume of software that we have. As software engineers we pride ourselves on our systemic thinking, so it's tempting to look at the situation and say "we can and should do better". But it's an illusion to think of software ecosystems as being designed. The reality is individuals, teams and even huge companies are constrained by ecosystems which are too big to really control and optimize in a systemic fashion. Useful software today beats perfect software tomorrow. That's why software is not well-optimized: because less optimized software beat it to market at multiple layers of the stack. That's why web apps slowly killed native apps: because shipping binaries to multiple platforms is way harder than loading a URL in a browser (or thin wrapper thereof). One thing I've learned the hard way in life is to focus on what one can control. We may not like the tradeoffs others have made and the systemic outcomes they led to, but we can't control them. A better tactic is to pick one very specific area you think you can make a dent and focus on that.

routerl 4y ago
> A better tactic is to pick one very specific area you think you can make a dent and focus on that. Amen. Best practices taught me "don't break extra windows, and repair broken ones as you find them", but I'm finally at a point in my career where I can say, with confidence, that some broken windows aren't worth fixing; you might have enough expertise to know that it should be fixed, while simultaneously lacking the expertise to do so in a cost-effective way. Case in point: in the iOS app I'm currently working on for a client, my team discovered a bug that was, very clearly, an interest payment on the technical debt the client has been accruing. The "correct" bug fix would entail rewriting a lot of existing functionality (i.e. paying down a big chunk of the principal, on the technical debt). This was not cost effective for us, since we were being paid to fix the bug as written. So we fixed the bug, while introducing functionality that could, in the future, be used to pay down the tech debt principal, should the client desire to do so. Spoilers: the client will never desire to do so, and therefore we've actually just added cruft to the codebase. But this conclusion is not allowed, in the client-provider relationship; the bug is fixed, therefore contract conditions have been met, therefore the work is done. The cause of bad software is, simply, that the incentive structures and scheduling required for making good software don't usually exist.

thewebcount 4y ago

I don’t disagree with the sentiment of the article. But it really does seem to be dependent on the type of work you’re doing. In 2000, I started writing plugins for Final Cut Pro. You could write “real time” plugins for it! That meant you were working in YCbCr 4:2:2 at 320x240 and 30 frames per second (so quarter-sized frame, with 2/3rds the data that an RGB frame would carry and half as often). 22 years later, I’m still writing such plugins, but on the top-end systems you get multiple streams of 8K uncompressed RGB video at 60fps and you can play back in real time. Some things really have gotten significantly faster. But yeah, using a web browser to do normal tasks like display emails is insanity and very very wasteful.

rileymat2 4y ago

> Windows 95 was 30MB. Today we have web pages heavier than that! Windows 10 is 4GB, which is 133 times as big. But is it 133 times as superior? This is an interesting question, I am not sure how I would measure this. Stability/Uptime is probably 100x better than I recall for my windows 95 machine. They have done a ton of important security work since 95, from UAC to process isolation. Would I pay 100x more? I am paying less now.

capableweb 4y ago

Previous threads, with lots of discussions: - 317 points | Sept 18, 2018 | 96 comments | https://news.ycombinator.com/item?id=18012334 https://news.ycombinator.com/item?id=18012334 - 934 points | Jan 1, 2020 | 498 comments | https://news.ycombinator.com/item?id=21929709 https://news.ycombinator.com/item?id=21929709

dang 4y ago
Thanks! Macroexpanded: Software Disenchantment (2018) - https://news.ycombinator.com/item?id=27775262 https://news.ycombinator.com/item?id=27775262 - July 2021 (1 comment) Software Disenchantment - https://news.ycombinator.com/item?id=27041180 https://news.ycombinator.com/item?id=27041180 - May 2021 (4 comments) Software Disenchantment (2018) - https://news.ycombinator.com/item?id=21929709 https://news.ycombinator.com/item?id=21929709 - Jan 2020 (488 comments) Software disenchantment - https://news.ycombinator.com/item?id=18012334 https://news.ycombinator.com/item?id=18012334 - Sept 2018 (94 comments) Software Disenchantment - https://news.ycombinator.com/item?id=17996272 https://news.ycombinator.com/item?id=17996272 - Sept 2018 (1 comment)

azanar 4y ago

We could perhaps get better software, but at what cost? One of the nice things about engineering disciplines is that costs can be reasonably forecast. There are spectacular counterexamples (e.g. Big Dig), but bear in mind those projects were much more than "just" engineering projects. Software costs seem hard to forecast. Software integrates with other software. Software is created via a whole pantheon of algorithms. The "better" algorithm is often context dependent. That context depends on what else gets integrated. Did I mention we probably won't know at the design phase how things will be integrated? Other engineering disciplines integrate with things that are well-known: the ground, water flows, the atmosphere. These things don't change. This is nice. This article makes it sound like "better" is just a matter of spending more. My read is different: spend more and be correct. Correctness _isn't_ just something we know but aren't allowed to implement. In many cases, we don't _know_ what correct is. We have to _find_ correct via exploration and experimentation. Even when we do, we might severely misjudge the effort required to get there. This complexity isn't just accidental. The world is a complex place. Our human minds act on a small portion of that complexity, based on all sorts of heuristics we aren't even conscious of. They work most of the time. The rest of the time? We're compelled to shoehorn things into our heuristics. This ends increasingly poorly the more complex the underlying mechanism is. This is a hard argument to make to someone who will not accept that they are not correct. Correct in their criticism. Correct in their diagnosis. Correct in the the behaviors that lead to our condition. Correct in asserting that avoiding those behaviors would result in no unanticipated consequences. Resentful about it because they were correct, and we didn't accept that.

oldjavacoder 4y ago

"We put virtual machines inside Linux, and then we put Docker inside virtual machines..." Hold my beer.

RivieraKid 4y ago

An observation I had while working in IT is that programming involves a lot of detail which is hard or impossible to notice from the outside (project managers, testers, users). And the average programmer is quite bad and doesn't have a perfectionist mindset. For example, let's say someone writes code which reads and parses 1 MB JSON file on every keystroke. From the outside, this is usually undetectable. Whenever someone makes something 10% slower or larger, adds a non-obvious error or implements a feature with 10x more complexity than possible, it's often barely distinguishable from a much higher-quality implementation.

garrisonj 4y ago

I would switch music streaming services for a client that wasn’t buggy. I think there is an untapped market for a software company that provides high-quality software. Market competition might kick in if a company can pull it off. It's probably more complicated than it sounds, though, because software frameworks don't provide that level of quality.

narag 4y ago

There's a couple of points in the article that I don't see discussed here. One is the comparison with games. So the article is about other categories of software. Has someone thought of other kind of "gamification"? I sometimes think that I'd love to see some fancy gaming interfaces outside games. The other is that, forget about solutions, frustration is a very powerful force and it has consequences. Frustration for the users and also frustration for programmers. This used to be a job considered interesting and fulfilling.

z3t4 4y ago

All software is shit, the more you have the bigger the pile. So if you want to write a fast and bug free program, make the scope as small as possible.

dinvlad 4y ago

"Back in the days" I used to think 256KB of RAM on a modified Speccy was already plenty, and dreamt about getting one of those 256MB(!) PCs, which would open a _universe_ of opportunities. Heh, that was so naive - not because of it being possible in principle, but mostly because of all the bloat described in this article, plus misaligned business incentives. These days, writing any software that would fit within mere dozens of KBs like the famous .kkrieger (an entire better-than-original-Doom-looking FPS game!), seems almost out of reach. Although it's motivational to dream once again through projects like Redbean that everyone is posting about. But at the same time, I feel like unless you've lived through those times, it's sort of a "lost art" and is only appreciated by a vast minority these days. In other words, the whole idea of minimalism in software is not even thought about as something that existed/could exist (you can't imagine a yellow Jeep if you've never even heard of a Jeep..)

galaxyLogic 4y ago

It's bit like "shrinkflation" where you get less for the same cost because that reduces producers' expenses. In software we get the same functionality as 20 years before on similarly priced hardware. But we don't get the speed-benefits we could and should expect. This may be because software producers prefer making things easy for themselves by using ever larger libraries. It reduces their costs but makes software slower?

z3t4 4y ago

> Linux kills random processes by design Linux will only kill processes if there are no swap left. So always have swap. You can also configure what Linux should do when there are no memory left.

trinovantes 4y ago

Be careful making your software too quick or else your client might think something is broken

cageface 4y ago

Analogies comparing software to most other forms of engineering are not usually very helpful. The considerations and constraints that inform automobile design are totally different than those of a typical mobile app or CRUD web shop. We know how to build software that’s efficient and reliable. It’s a slow and expensive process. If anything discourages me about software engineering it’s that so many of us don’t seem to be able understand that the nature of our discipline is different.

bmitc 4y ago

This rings true and frustrates me as well. My entire career I get bogged down with being so disappointed with the tools that we use in the software industry, that it totally distracts from building new things. Perhaps it is my mathematics background that spoiled me. In mathematics, you rarely are concerned with the tools that you have at your disposal. In most cases, they have been designed well, iterated on, smoothed out, etc., and above all, they just work. Aside from the most advanced, cutting-edge work, this is generally true. Of course, there's always work on foundations, different paradigms of mathematics, and more, but I think the point is clear. Maybe an even clearer point is imagining a carpenter who has to rebuild his hammer every day because it stops working, and then imagine that the instructions to build a hammer are practically undocumented scribblings on some napkins. In software, and actually in engineering as a whole, there is a large percentage of work that goes into solving problems created by other engineers. This isn't all the work, of course, but it is a depressingly large amount. In general, I am less concerned about all the constraints of software artifacts, e.g., size, slowness, etc. While those are a drag and can be frustrating, I am more concerned with two things: software that works and software tools. The tools that we use in this industry are nothing but antiquated. Software engineers equate programming to text, and thus, all the tooling revolves around text. Most so-called IDEs are simply advanced text editors. Tools like Git are beloved, and in Linus' own words, I'm surprised they made it to adulthood. Even in a text-based language, I absolutely do not care about lines that changed. I care about semantic things, like functions, modules, expression blocks, etc. I want my source-code control and comparison tools to tell me what actually changed and not what characters of changes are present. I could go on and on this topic. And part of the consequences of poor tools, we have software that works poorly and is just balls of mud stacked on top of more balls of mud that have dried out they're brittle to even touch. But that's just one component of why software doesn't work. The other is how we think about software. Thinking about software as just a thing that a person tells a computer to do is not enough. Software is about three things: (1) computation, (2) communication between humans and not between human and machine, and (3) how to think about things or encode a domain with software. We suck enough as it is with (1), but (2) and (3) are basically ignored at large. Almost all engineering problems in deployed systems relate down to communication issues and poor understanding of the domain at hand. But not only does everyone concentrate on (1), they concentrate on very narrow aspects of (1). It's almost no surprise that things are as bad as they are in software.

EdwardDiego 4y ago

On the plus sides: * I haven't had to specify IRQ or DMA to listen to music in a long time. * I plug stuff into my USB / thunderbolt ports, and _it just works_, even though I'm running Linux * I can play games on Linux, real actual commercial ones, not just ones involving Tux the penguin * I can send my Mum videos and she can watch them without worrying about codecs, without me having to explain what a codec is. Software is awesome these days. Could we do better? Always, was it better in the "good ol days"? Hell no.

gyamet 4y ago

Not all software is crap. I've had my game server for a popular multiplayer online web game running continuously for over two years now. Same Linux process, same cloud VM. Never crashed, never needed to reboot. Node 12, everything done in TypeScript, from the network protocol to the physics engine. All it took was careful design and development. Not that difficult if you put your mind to it and don't cut corners.

amtamt 4y ago

Read on another link... Voyager had 67kB RAM in it's computers and has reached the end of solar system. We really need to rethink system design and implementation.

0x69420 4y ago
a good general-purpose multilingual text and graphics layout engine does in fact turn out to be a computationally harder problem than reaching the end of the solar system, sorry

kvark 4y ago

One of the signs of an apocalypse/bloat is latency. Watching the industry from the intel 386 era, I’m only seeing it increasing. Every little action takes longer to start. It feels like we (in a larger sense) focused too much on throughput:) The perfect latency device I held was Nintendo DS.

FridayoLeary 4y ago

I am immediately reminded of this saying: "Anyone can build a bridge that stands, but it takes an engineer to build a bridge that barely stands". I guess Nikitionsky wants to apply the same standards to software engineering.

robocat 4y ago

Agree with the gist, but some of the examples are so poorly informed that the whole article is tainted. > Google’s keyboard app routinely eats 150 MB. Is an app that draws 30 keys on a screen really five times more complex than the whole Windows 95? Calling it 30 keys is silly, and undermines their argument because it certainly isn’t 30 keys. How many MB is reasonable for features I use like the swipe feature? For Chinese entry? For spelling support? > Google Play Services, which I do not use (I don’t buy books, music or videos there)—300 MB that just sit there and which I’m unable to delete. The writer is showing their absolute ignorance of what Google Play Services does - a better name would be Android System Services. Maybe question the need for 300MB, but use some intelligence rather than just making crappy off-the-cuff strawman arguments.

rozhok 4y ago
So what exactly does google keyboard and google play services? Why it consumes so much space? REAPER (http://reaper.fm/download.php http://reaper.fm/download.php), the full-fledged complex desktop application (DAW) weights only 15MB.

chadcmulligan 4y ago

Isn't this a web developers lament? Look at native code or the wonderful world of 3d graphics, speed is piling on. But look at web development with the layers of frameworks to display a text box. The solution seems fairly obvious I would have thought.

int_19h 4y ago
No, it's also a lament of every desktop user & dev, because we get more and more web apps repackaged in Electron, with all that entails perf-wise.

EVa5I7bHFq9mnYK 4y ago

It took me 20 seconds to compile and link a program on my PDP 11 with 64k of memory (yes, 64k for the OS plus all the drivers plus user programs). It still takes me around 20 seconds today with 1,000,000 times more memory and ~10000 times faster processors.

fungiblecog 4y ago

the irony of this is that we have all the bloat but we also have to live with decisions that were only made because of the limitations of the past. I'm referring to things like arbitrary limits on filename lengths. And worst of all databases that think it's a good idea to make you delete information by default to "update" it rather than keeping all the changes. Disasterous.

1vuio0pswjnm7 4y ago

"That is not engineering." It does not stop the folks that do it from calling themselves "engineers". When faced with the potential for being regulated, large "tech" companies that lobby regulators claim they can regulate themselves. "Tech" companies also believe they can redefine what is "engineering" and hire "engineers" who have no corresponding certifications. In some cases, the companies themselves are the certification providers. History has shown that self-regulation does not work. Nor do blog posts complaining about declining software quality.

hsn915 4y ago

There are many ways to be disgruntled by this, but IMO you should instead think of it as an opportunity. If the world was full of well behaving well designed software, it would be difficult to find useful things to contribute. Since the world is full of bad software written by, well, other programmers, this is just a chance for you. Take it. Quit your job and do something useful.