SoylentNews is people
SoylentNews
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
This discussion has been archived.
No new comments can be posted.
On Disenchantment with the Current State of Software Development
|
Log In/Create an Account
| Top
| 99 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
To be a kind of moral Unix, he touched the hem of Nature's shift.
-- Shelley
(Score: 0) by Anonymous Coward on Wednesday October 03 2018, @10:49PM (7 children)
As long as that is understood, programs can be designed to easily survive that - by adding a separate abstraction layer which is in charge of all OS interaction, and which does not expose any not directly needed functionality to the rest of the program. This way, effects of an API change are localized and multiple alternate APIs are easy to support.
(Score: 5, Interesting) by fyngyrz on Wednesday October 03 2018, @11:26PM (4 children)
FTFY.
The problem (aside from the considerable extra work and various performance penalties) is that not all useful software is under development. Several of the applications I use no longer have companies behind them for one reason or another; there's no one who will be able to manipulate the abstraction layer. So when the OS API breaks, that's the end for them. Assuming one indulges in the new OS and can't get a VM set up with the old one to carry on, albeit inconveniently.
Some things are more than API-deep, too. Apple's planning to outright break support for 32-bit applications in an forthcoming OS release. I have a lot of software that's 32-bit; most of these aren't in any way lacking in functionality, or buggy, yet Apple is going to break them completely. They'll end up running in a VM as well under an earlier version of OS X, because of course there's no actual reason they can't keep running, other than Apple being Apple, which is to say, being customer-screwing boneheads.
Then there's this. I write software under QT, which is essentially an abstraction layer. I do this so that I can variously generate versions for OS X, Windows, and linux from my projects. QT, however, often plays the "let's break it!" game; apps developed under QT 4.8 that are warning- and error-free generate literally tens of thousands of errors when an attempt to build them is made under QT 5. Furthermore, applications generated under QT 5 won't run on OS versions that applications which were generated under QT 4 will run on — 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.
This in turn demonstrates that unless you write your own abstraction layer, you can be bitten by exactly the same factors. And a decent abstraction layer is no trivial thing; QT again demonstrates this both by its depth, and its considerable load of bugs and problems, which, just like the OS vendors, it tends to leave unfixed and lying around in favor of "Hey look, New! Shiny!"
I have asked myself multiple times if it would be worth my time to write my own abstraction layers. Each time, the answer is no. So instead, I develop under as far back an OS and abstraction layer as I can get away with, adding my own functionality similar to new OS / abstraction features being offered as needed. Which, to be honest, doesn't happen all that often. But one example of this is that QT as of versions 4.8-ish didn't provide USB support worth a shit, so I wrote the needed classes for OS X, Windows, and linux. It took a lot of time and care to do it, but now, at least, I have it when I need it.
Bottom line, the only real fix here WRT new OS and related abstraction layers is proper legacy API care from the OS and abstraction layer vendors. And we all know that's not going to happen.
(Score: 0, Disagree) by Anonymous Coward on Thursday October 04 2018, @09:06AM (3 children)
FTFY. Let's not forget the obvious.
...get bitten by dev team's every whim, err, "good idea"?
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.
(Score: 2) by fyngyrz on Thursday October 04 2018, @01:28PM (2 children)
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. :)
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
victimsusers 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.No. Not my problem.
(Score: -1, Troll) by Anonymous Coward on Thursday October 04 2018, @02:04PM (1 child)
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
Yes? Show your work. I'm perfectly ready to believe you... on that basis. Otherwise, not a chance. :)
(Score: 2) by MichaelDavidCrawford on Thursday October 04 2018, @03:56AM
The ZooLib C++ Application Framework [github.com] has the MIT License, specifically to encourage both open source and proprietary use.
Andy Green [em.net] write its first version on top of Mac OS so as to insulate himself from Bedrock, which Apple shouted from the rooftops would enable cross-platform windows and mac apps. Andy didn't want to have to rewrite all his products when bedrock shipped - which it didn't - so he figured he would just implement a bedrock shim underneath zoolib.
From there it was not hard at all to write a windows 3.1 shim.
These days, ZooLib has a cocoa and a cocoa touch shim. So I could recompile the Win/Mac app I wrote in 2000 to run on the iPad, which I actually intend to do in my infinite free time.
I write an essay called "Why ZooLib" for its original website, which Andy took down in favor of just using GitHub. I asked him if I could say that "ZooLib frees the developer from OS vendor shackles."
Andy's reply?
"Quite."
Yes I Have No Bananas. [gofundme.com]
(Score: 2) by jmorris on Thursday October 04 2018, @05:15PM
Guess what champ, you juts became part of the problem when you do that. What is the word you would use to describe your "abstraction layer"? Yup, you just created yet another API / Framework that, being a one off for your product, will be buggy and poorly maintained and likely have inadequate documentation. After a few years you will think so highly of it that you unleash it on the world as yet another abstraction framework where it will join the others in sucking. Programmers will program to your ABI as it mutates and changes and they curse your name. And then some moron, having learned nothing, will, within the cubefarm of some vast software shop out there, write a nasty little library to abstract away the churn in your ABI and allow a block of code to build against multiple versions of it and later add some code to let code built against this new abstraction library perhaps build on an entirely different platform or widely deployed abstraction ABI. A co-worker will learn of it and want to use it, some internal docs will get written....
And the wheel turns.