Stories
Slash Boxes
Comments

SoylentNews is people

posted by chromas on Wednesday October 03 2018, @09:12PM   Printer-friendly
from the the-future-is-now,-old-man dept.

Nikita Prokopov has written a blog post detailing disenchantment with current software development. He has been writing software for 15 years and now regards the industry’s growing lack of care for efficiency, simplicity, and excellence as a problem to be solved. He addresses the following points one by one:

  • Everything is unbearably slow
  • Everything is too large
  • Bitrot
  • Half-baked products get shipped
  • The same old problems recur again and again
  • Most code has grown too complex to refactor
  • Business is uninterested in improvement

Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0, Disagree) by Anonymous Coward on Thursday October 04 2018, @09:06AM (3 children)

    by Anonymous Coward on Thursday October 04 2018, @09:06AM (#743949)

    Open source SW can be insulated against API changes

    FTFY. Let's not forget the obvious.

    I write software under QT, which is essentially an abstraction layer. I do this so that I can

    ...get bitten by dev team's every whim, err, "good idea"?

    so I face the issue of screwing some subset of my users if I move those projects to QT 5. Do I want to do that? No. I really don't.

    Which is exactly why you should bite the bullet and add an intermediate layer. You'll waste more time and effort fighting the constant churn - and losing - than it takes to isolate the high-level UI logic from the gritty details of actual API calls, and then add pluggable support for "new-and-improved" QTs at your leisure.
    Besides getting an option to then add support for another toolkit with minimal effort.

    The API churn is the new normal. Forget the gone epoch of stable libs. And we need to design our code accordingly.

    Starting Score:    0  points
    Moderation   0  
       Disagree=1, Total=1
    Extra 'Disagree' Modifier   0  

    Total Score:   0  
  • (Score: 2) by fyngyrz on Thursday October 04 2018, @01:28PM (2 children)

    by fyngyrz (6567) on Thursday October 04 2018, @01:28PM (#744057) Journal

    Open source SW can be insulated against API changes

    FTFY. Let's not forget the obvious.

    Open source software may be actively developed beyond that which the originator indulges in. Or it may not. That depends entirely on developers with the appropriate skillset(s), interests, and available time and energy, a combination for which there is absolutely no guarantee. The only developer you can control as far as maintaining software goes is either an employee, or yourself. Everything else, including the entire open source world, is some combination of random, undependable, luck-based, popularity-based, or toxic.

    For instance, I have built a fair number of open-source projects of my own; I have yet to see a commit or code submission (prior to git) from anyone else, ever. There are thousands of users across all these projects (not counting the tens of thousands for my closed source projects, commercial and otherwise), and certainly they would benefit from the attention of others — added features, moves from (for example) Python v2.7 to v3.x, etc. But no. To date (many years now, I've been writing software since the 1970's), if it was going to get done, I've had to do it, or assign an employee to do it.

    Also, when an open source project is actively developed, it fits in perfectly with my original statement. So you didn't fix anything. Sorry. :)

    Which is exactly why you should bite the bullet and add an intermediate layer. You'll waste more time and effort fighting the constant churn - and losing

    Wrong. It's very clear you have no idea whatsoever of the magnitude of such a task.

    Furthermore, until Apple dumps that "32-bit only" thing on everyone like the load of utter shite it is, I'm not fighting churn at all, because I stick with the OS and abstraction layers I started with (Windows has been no problem... they do back-compatibility far better than Apple does. Linux is pretty good at it as well.) This means that to date, I only have had to deal with how the new Apple OS is back-compatible with the old abstraction layer, and that's about the lowest possible load there is in that context. For example, when an application was developed under QT 4.8, that's where I keep it. That means the APIs I'm dealing with are stable, if nothing else; they may have bugs, but as I find them, I can work around them, and eventually they sink below the noise level, which means things become more reliable, not less.

    Even after Apple shits on everyone, there will be VMs to turn to. That's the golden fix for the userbase, as it provides envelopes within which properly written software can continue to serve the users as they need them to, despite malfuckery on the part of the OS vendor(s), Apple in this instance.

    For my own development, the key I have found is to ignore the "New! Shiny!" that the OS vendors are always pushing at their victims users and developers, and concentrate instead on functionality aimed straight at the user vertically aligned with the core competence of the application, which in my case is most often a language, an image manipulation related application, or an SDR radio application.

    add pluggable support for "new-and-improved" QTs at your leisure.

    No. Not my problem.

    • (Score: -1, Troll) by Anonymous Coward on Thursday October 04 2018, @02:04PM (1 child)

      by Anonymous Coward on Thursday October 04 2018, @02:04PM (#744075)

      Wrong. It's very clear you have no idea whatsoever of the magnitude of such a task.

      Give me a couple minutes to stop laughing at your lousy telepathy. Thanks.
      I simply sat and done it, instead of bitching. I do not talk about hypotheticals. But if you're sure the task is too great a "magnitude" for you, then it most certainly is.

      • (Score: 2) by fyngyrz on Thursday October 04 2018, @10:20PM

        by fyngyrz (6567) on Thursday October 04 2018, @10:20PM (#744360) Journal

        I simply sat and done[sic] it

        Yes? Show your work. I'm perfectly ready to believe you... on that basis. Otherwise, not a chance. :)