Slashdot Mirror


'It Just Seems That Nobody is Interested in Building Quality, Fast, Efficient, Lasting, Foundational Stuff Anymore' (tonsky.me)

Nikita Prokopov, a software programmer and author of Fira Code, a popular programming font, AnyBar, a universal status indicator, and some open-source Clojure libraries, writes: Remember times when an OS, apps and all your data fit on a floppy? Your desktop todo app is probably written in Electron and thus has userland driver for Xbox 360 controller in it, can render 3d graphics and play audio and take photos with your web camera. A simple text chat is notorious for its load speed and memory consumption. Yes, you really have to count Slack in as a resource-heavy application. I mean, chatroom and barebones text editor, those are supposed to be two of the less demanding apps in the whole world. Welcome to 2018.

At least it works, you might say. Well, bigger doesn't imply better. Bigger means someone has lost control. Bigger means we don't know what's going on. Bigger means complexity tax, performance tax, reliability tax. This is not the norm and should not become the norm. Overweight apps should mean a red flag. They should mean run away scared. 16Gb Android phone was perfectly fine 3 years ago. Today with Android 8.1 it's barely usable because each app has become at least twice as big for no apparent reason. There are no additional functions. They are not faster or more optimized. They don't look different. They just...grow?

iPhone 4s was released with iOS 5, but can barely run iOS 9. And it's not because iOS 9 is that much superior -- it's basically the same. But their new hardware is faster, so they made software slower. Don't worry -- you got exciting new capabilities like...running the same apps with the same speed! I dunno. [...] Nobody understands anything at this point. Neither they want to. We just throw barely baked shit out there, hope for the best and call it "startup wisdom." Web pages ask you to refresh if anything goes wrong. Who has time to figure out what happened? Any web app produces a constant stream of "random" JS errors in the wild, even on compatible browsers.

[...] It just seems that nobody is interested in building quality, fast, efficient, lasting, foundational stuff anymore. Even when efficient solutions have been known for ages, we still struggle with the same problems: package management, build systems, compilers, language design, IDEs. Build systems are inherently unreliable and periodically require full clean, even though all info for invalidation is there. Nothing stops us from making build process reliable, predictable and 100% reproducible. Just nobody thinks it's important. NPM has stayed in "sometimes works" state for years.

13 of 560 comments (clear)

  1. Why should they? by QuietLagoon · · Score: 5, Insightful

    We've been trained to be a consuming society of disposable goods. The latest and greatest feature will always be more important than something that is reliable and durable for the long haul.

    1. Re:Why should they? by Anonymous Coward · · Score: 5, Insightful

      and our kids and grandkids will be buried in our electronic wastes.

      corporate greed is to blame (the consumer, less so). forced obsolescence for the sake of profits and with zero regard to the environment.

    2. Re:Why should they? by JuliceMTL · · Score: 5, Insightful

      Quick question ... do you always buy the cheapest car possible? I'm pretty sure you don't. This fantasy that consumers always go for the cheapest product is false and blaming consumers for the industry's lazyness and lack of vision is also lazy IMHO. Cheers

    3. Re:Why should they? by lgw · · Score: 5, Interesting

      There is a big chunk of consumers, probably 20%, that always buy the cheapest possible thing without regard to quality. It's the market Walmart caters to, and I have no problem with businesses that explicitly target "cheap". But that should be a niche, dammit!

      --
      Socialism: a lie told by totalitarians and believed by fools.
    4. Re:Why should they? by Nidi62 · · Score: 5, Insightful

      The kind of quality and efficiency that the summary seems to be talking about is expensive. The buying market wants cheap. Creating cheap solutions means grabbing third-party libraries and gluing them together....as much as possible. Once it basically works you just move on. That keeps development costs low and time to market low, which is exactly what the market wants.

      To use the Apple example in the summary, Apple could create lean and efficient software for their phones without raising costs to consumers. But then they would go from making a metric shit ton of profit to only making a standard shit ton of profit and we can't have that, can we? It's not that the people have decided what they want, corporations have told people what they want and the people lapped it up, even when it is quite clearly not in their best interest.

      --
      The only thing necessary for evil to triumph is for it to be pitted against a slightly greater evil
    5. Re:Why should they? by LucasBC · · Score: 5, Interesting

      Poor software engineering means that very capable computers are no longer capable of running modern, unnecessarily bloated software. This, in turn, leads to people having to replace computers that are otherwise working well, solely for the reason to keep up with software that requires more and more system resources for no tangible benefit. In a nutshell -- sloppy, lazy programming leads to more technology waste. That impacts the environment. I have a unique perspective in this topic. I do web development for a company that does electronics recycling. I have suffered the continued bloat in software in the tools I use (most egregiously, Adobe), and I see the impact of technological waste in the increasing amount of electronics recycling that is occurring. Ironically, I'm working at home today because my computer at the office kept stalling every time I had Photoshop and Illustrator open at the same time. A few years ago that wasn't a problem.

    6. Re:Why should they? by Mark+of+the+North · · Score: 5, Interesting

      Can you really not see the connection between inefficient software and environmental harm? All those computers running code that uses four times as much data, and four times the number crunching, as is reasonable? That excess RAM and storage has to be built as well as powered along with the CPU. Those material and electrical resources have to come from somewhere.

      But the calculus changes completely when the software manufacturer hosts the software (or pays for the hosting) for their customers. Our projected AWS bill motivated our management to let me write the sort of efficient code I've been trained to write. After two years of maintaining some pretty horrible legacy code, it is a welcome change.

      The big players care a great deal about efficiency when they can't outsource inefficiency to the user's computing resources.

    7. Re:Why should they? by arglebargle_xiv · · Score: 5, Informative

      There is one place where people still produce stuff like the OP wants, and that's embedded. Not IoT wank, but real embedded, running on CPUs clocked at tens of MHz with RAM in two-digit kilobyte (not megabyte or gigabyte) quantities. And a lot of that stuff is written to very exacting standards, particularly where something like realtime control and/or safety is involved.

      The one problem in this area is the endless battle with standards morons who begin each standard with an implicit "assume an infinitely fast CPU with infinite RAM...". The number of standards meetings I've sat through where we've been met with total incomprehension, I mean literally a total inability to comprehend, that something has to operate on anything less than a multi-GHz CPU with gigabytes of RAM....

  2. When you're right, you're right. by pushf+popf · · Score: 5, Interesting

    Nobody has a clue anymore whether they're building on a poured concrete foundation or a bag of cats.

  3. Moore's law by Anonymous Coward · · Score: 5, Interesting

    When the speed of your processor doubles every two year along with a concurrent doubling of RAM and disk space, then you can get away with bloatware.

    Since Moore's law appears to have stalled since at least five years ago, it will be interesting to see if we start to see algorithm research or code optimization techniques coming to the fore again.

  4. Welcome to the world of perpetual growth by Opportunist · · Score: 5, Interesting

    Perpetual growth also means selling more than last time, and the only way to do that is to make people want your new stuff. This is possible only in two ways: First, your new stuff is so much better than the old one that people WANT it, or second, the old one is already broken so people have to buy it.

    Since inventing new stuff that people want badly enough to drop another wad of dough for it even though the old one's still working is hard but making stuff that breaks easily is easy...

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  5. Who fail to learn, re-implement Unix badly. by Seven+Spirals · · Score: 5, Interesting

    Unix solved most of the problems associated with an operating system. It's just that most folks don't take the time to learn their history or look at existing solutions. Instead NIH and "I can do it better" syndrome are the rule. I see this constantly on /. and elsewhere. Folks acting like very old technology is brand new, or acting like something that was invented yesterday isn't a blatant copy of previous tech. Even Window is still trying to catch up to technology that's been in various Unix variants for 20+ years. Unix is the way and the light. Specifically, I think the BSD's have the right mindset. As a nice bonus, the non-graphical installation runs off all the Ubuntites. Yay!

  6. The customer can't find it as an option by Anonymous Coward · · Score: 5, Insightful

    The customer has no choice in the matter. The people that make the decisions and hire/fire are the ones that do. Lets take a look at a typical DevOps or NoOps shop:

    1: The devs are mainly junior to intermediate level. Senior devs get the axe because they cost too much.
    2: What matters is getting deliverables that marketing has already sold to a customer.
    3: The devs are asked each day about said deliverables in the Scrum stand-up meeting.
    4: If the devs don't cough that deliverable up -yesterday-, they get replaced by someone else who can.

    In this environment, technological debt is someone else's problem. All that matters is getting stuff working and the code artifacts into production. Security, or readability? That's other people's problems.

    This is the modern company. The days of people writing code in assembly to get everything to work perfectly and still have room on a floppy disk are over.

    Blame the bad top brass, who short their stock before a security breach is announced so they can swing a new yacht, and who can't hear anything over their own ego. That is where the fault resides.