11–20 of 201 posts
The ending: "Things can be better. I'll show you how." It's just an intro for clickbait.
If only they had unveiled the single unifying abstraction of everything :(
(I kid, mostly :)).
> It's catastrophic when they don't." I have found this not to be the case. Very often, an inaccurate mental model is the ideal user state, and it's my job to afford and reinforce it. But that's just me, and my experience. I'm sure there's a ton of folks that have found better ways.
That doesn't mean I don't want abstractions. It means I think what constitutes a good abstraction is determined as much by how true it is as by how intuitively appealing it is. An abstraction that corresponds to a naive user's expectations but that doesn't accurately reflect (the essential/relevant aspects of) what is actually happening is not an abstraction, it's a lie.
Edit: And the tragedy of it is that users are, by and large, extremely good at figuring out the reality behind the lies that well meaning developers make their software tell. When our software breaks and misbehaves, its internal realities are surfaced and users have to navigate them, and more often than not they do, successfully. Internet forums are full of people reasoning, experimenting and fiddling their way to success with faulty lying software. Apple Community is perhaps the purest example of a huge population of users navigating the broken terrain behind the abstractions they weren't supposed to think about, with absolutely no help whatsoever from the company that built them. We should have more respect for users. If they were as dumb as developers assume they are almost none of the software we write would ever be successfully used.
The ending: "Things can be better. I'll show you how." It's just an intro for clickbait.
If only they had unveiled the single unifying abstraction of everything :(
Here you are: https://en.wikipedia.org/wiki/Category_theory
;-)
Abstractions themselves aren't a problem; they are in fact a necessity if you want to move anywhere beyond simple bit-twiddling. (Heck, even the idea of software itself is an abstraction over hard-wired instructions.) The real problem with abstractions is when they are implemented poorly, or have side-effects, or just plain bugs. In other words, we will always be at the mercy of human-produced software.
>The real problem with abstractions is when they are implemented poorly, or have side-effects, or just plain bugs. Which is always, and is why clean maintainable code uses minimal abstractions to accomplish the task. However it seems the default these days has become "pile it on".
So when people run explain on their SQL query, IMO you've broken the declarative abstraction.
In agile software development on the other hand, technical competence usually ends at the lowest tier. A scrum team has folks on it who make software, that's it. Then, lots of scrum masters, business analysts have probably never coded much; the first actual boss in the hierarchy has mostly secretarial and managerial work and will hardly look at code at all.
Point is, it's not just that software development is done in ticket-sized portions which does not invite philosophical considerations about the numbers of abstraction layers that one builds and maintains. It's that software developers don't even have a seat at the table(); they get babysat by scrum masters, make compromises during code review, are discouraged from thinking beyond the ticket, and are then of course not usually promoted into leadership roles to which they would bring their technical competence.
It appears therefore that any movements to bring awareness to the "software crisis" will be relegated to hobbyists, as the article states at the end: to "Handmade, Permacomputing, and various retro-computing circles".
() I partly blame Hollywood and their incessant humiliation of software/IT people, while creating endless leading roles for doctors and lawyers, effortlessly weaving their complicated terminologies into fascinating storylines, which is aparently not possible to do for us? Maybe the scriptwriting AIs can come up with something here soon.
* I do not argue against abstractions, but against the unrestricted application of them.
* I do not advocate for a reversion to more constrained platforms as a solution.
* I do not advocate for users becoming "more technical" in a "suck it up" fashion.
The key to understanding the software crisis is the curves of "mastery of a platform" and "growth/release cycles". We have, in the past 40+ years, seen these curves diverge in all but a few sectors. We did not address the crisis when these curves were close in proximity, but the second best time is now.
As for folks calling this clickbait, it is the first in my log, and reflects my thoughts on the situation we find ourselves in as developers. The sentiments are mirrored, in various forms, around multiple communities, some of them based in counterculture.
I do want to deliver some part of the solution to these problems, so I do intend on following up on "I'll show you how". I am a single entity, so give me time and grace.
Abstractions themselves aren't a problem; they are in fact a necessity if you want to move anywhere beyond simple bit-twiddling. (Heck, even the idea of software itself is an abstraction over hard-wired instructions.) The real problem with abstractions is when they are implemented poorly, or have side-effects, or just plain bugs. In other words, we will always be at the mercy of human-produced software.
>The real problem with abstractions is when they are implemented poorly, or have side-effects, or just plain bugs. Which is always, and is why clean maintainable code uses minimal abstractions to accomplish the task. However it seems the default these days has become "pile it on".
The “inscrutable layers unapproachable to beginners” of today are the bare metal low level computing of tomorrow. Sure I learned with DOS and Turbo Pascal and it was wonderful, but if you ask my teachers who learned with machine code and microcontrollers, they worried that computers have become too abstract and kids these days have little chance to learn the true details.
Hi! Author here. I think it's important to address certain aspects of this post that people tend to misunderstand, so I'll just list them here to save myself the effort. * I do not argue against abstractions, but against the unrestricted application of them. * I do not advocate for a reversion to more constrained platforms as a solution. * I do not advocate for users becoming "more technical" in a "suck it up" fashio…