Continuing the discussion from How should a person accused of racism respond?:
I thought the term was “technical debt”. Which makes sense, because you literally borrow technical knowledge.
But the internet tells me technical debt refers specifically to the opportunity cost of an easy programming solution over a robust one. So what is the right term?
“Hack” comes to mind but the connotation (skill required) seems wrong.
~Max
I would describe that as being a consumer of technology.
Technical Debt (in a broad sense) is when you fall behind on upgrading, adopting new technology, fixing things, etc (often because it’s financially costly to do the right things - one exchanges monetary savings for technical debt)
No, not really. Technical debt accrues when necessary tasks are pushed past a release. Shipping code with bugs, or leaving out features to make a release, knowing that the features will still need to be written, is a form of technical debt, Temporary workarounds are another. Basically, anything left undone in a previous release but still required is technical debt added to future releases.
Developers use code they don’t understand all the time. It can be commercial libraries, or it can be legacy code someone else in the company wrote, is necessary to the program, but not understood well by anyone still in development. I’ve seen more than one chunk of convoluted code with a warning, “Don’t modify. Here be dragons.” In other words, the code was so twisty and poorly understood (and coded) that any attempt to modify it was likely to introduce bugs or take the developer down a rabbit hole.
The reason we have accelerated development so much in past years is because programmers now have rich libraries of code to use, rather than having to cook up their own. Most developers today are little more than builders constructing applications by gluing together already-existing libraries which they may not understand at all. It’s so common I don’t think there is a name for it other than code reuse.
Technical debt is similar to the pile of stuff you have in your closet, piled up, that needs to be sorted - half thrown away - and put away properly. It’s something you hope you can keep avoiding, in perpetuity, but do actually need to do.
You’re describing what script kiddies used to do. They have a rough understanding of what something can be used for, but they don’t properly understand how it works, may or might not be using it to it’s full extent, and certainly couldn’t build it on their own.
I don’t know that there’s a term for that activity, just the doers.
Semi-technologically literate?
I think “black box” is the term you’re looking for.
Programming in a black-box paradigm mainly consists of having functions or methods that hides the inner workings from the user (programmer). These functions take a set number of parameters and produce the given output without the developer having to worry about how the actual logic is implemented.
One nasty recent result for reusing libraries:
A newly discovered zero-day vulnerability in the widely used Java logging library Apache Log4j is easy to exploit and enables attackers to gain full control of affected servers.
Tracked as CVE-2021-44228, the vulnerability is classed as severe and allows unauthenticated remote code execution as the user running the application utilises the Java logging library. CERT New Zealand warns that it’s already being exploited in the wild.
Which applications are affected by the Log4j flaw?
Because Log4j is so widely used, the vulnerability may impact a very wide range of software and services from many major vendors. According to NCSC an application is vulnerable “if it consumes untrusted user input and passes this to a vulnerable version of the Log4j logging library.”
How widely is the Log4j flaw being exploited?
Security experts have warned that there are hundreds of thousands of attempts by hackers to find vulnerable devices; over 40 percent of corporate networks have been targeted according to one security company.
Some might say that the Log4j clusterfuck is simply a nasty result of using Java.
There’s also a difference between knowing how to effectively use parts a pre-made class or api and being intimate with how it’s coded.
I mean I don’t think it’s terribly important to know how a B-tree class works under the hood, as long as you know how one works and why/when you use them, and how they differ from an AVL tree.
Now if it’s what a buddy of mine calls “cargo cult” programming, where chumps just cobble together chunks of others’ code, not just using stuff from libraries or api,s, and hope it works, then yeah that’s awful.
Okay, okay. I know the term is not technical debt.
Some examples, I suppose.
@TroutMan: Black box is good, and would be perfect if it is used as an adjective or verb. But I don’t think that is the case, is it? Does it make sense to say “Bob black-boxed the vector class”, and does that imply that his mental model was flawed?
~Max
I think script kiddies is close, it implies copy & pasting in addition to a lack of understanding, but that describes the person and not the act or attitude.
~Max
It might make sense depending on how you feel about verbing nouns.
Black-box programming absolutely does not imply a flawed mental model. It is the proper way to code. If you’re talking about cobbled-together crap like bump describes, I’d say “Bob copy/pasted the vector class.” That could be neutral or a put-down depending on tone and context.
It is, exactly that. If you follow the link, i brought it up as a case of dealing with being told your language is culturally insensitive. A friend wrote the following on Discord channel i use:
I’m very behind on this channel, but I did want to say I would appreciate if we didn’t use the term “cargo cult programming” in this venue. The term is based on a reference to “cargo cults”, which is an extremely problematic and pejorative term for a complicated phenomenon that rose out of colonialism.
So folks were looking for other ways to express that idea.
Button pusher
That means almost the opposite, really. If the existing vector class was “leaky”, with a bunch of exposed implementation details, then Bob could be said to have black-boxed the class if he cleaned up the interface to hide those details. But that process would require understanding how the class worked in the first place.
“Black-boxed” is a little awkward and I wouldn’t use it in that manner, though–I’d say “abstracted”.
“Cargo cult programming” is the closest phrase I know to refer to coding without any idea of the underlying implementation.
A related phrase is “leaky abstractions”. These are situations where the underlying details are exposed–often by causing a bug or performance issue. All abstractions are leaky, to some extent, but some are worse than others (ones that cause security bugs are the worst). A cargo cult programmer may have no idea how to deal with these issues when they inevitably arise. Sure, it’s a defect in the code module but given how common these defects are, it’s a very useful skill to dig down into the details to root out the real issue. One of the biggest lies I was told in my programming classes is that compilers don’t have bugs.
You would think there is a more general term than “cargo cult programming”. The meaning would be roughly: to copy or appropriate some technology for use in a new situation without fully understanding how it works, especially with a flawed mental model for its use.
Moving out of the programming context,
~Max
At this juncture, everyone should take a moment to read The Law of Leaky Abstractions by Joel Spolsky.
The Law of Leaky Abstractions:
While you’re there, read all of his other essays too, if you haven’t already.
I was going to say “abstracted” as well. That’s basically how advanced technology works. The more complex underlying technology that makes it work is “abstracted” so you just tell it “do this” as opposed to writing all the detailed commands.
That has a negative connotation, and isn’t really accurate. A more technical term would be ‘interface-based programming’. The idea is that all you should have to know about using a class is contained in the interface. In fact, the whole point is that the underlying code could be changed at any time without breaking applications. You should simply not care what the implementation looks like, so long as it meets the specifications advertised and implements the interface.
A good example in hardware is building circuits out of discrete integrated circuits without having to understand the internal design of ICs. Everything you need to know is contained in the interface. In the case of ICs that would be the pinouts and data sheets. If everyone had to understand the internal implementation of every IC used, nothing would get built.
It is absolutely standard, and proper programming prqctice, to modularize software as we do with hardware and to define classes through interfaces without needing to know any implentation details.
An older term for this was ‘modular programming’.
The cargo cult analogy falls apart because the key flaw of cargo cults was the confusing of cause and effect. People putting headsets on and talking theough microphones was not the cause of airplanes coming to the islands, but the Islanders thought it was so they replicated those details as best they could, and failed. It was essentially a demonstration of category error.
Also, they had nothing to do with colonialism. The reason the cargo cults cropped up was because the soldiers and air forces didn’t stay and colonize those islands after the war was over.
Having no knowledge of the underlying details is a significant limitation and should have a negative connotation.
The cargo cults didn’t fail because they didn’t know how to wear their coconut headsets correctly. That part they got right. They just didn’t know the difference between something shaped like a headset vs. an actual headset. If they had the slightest knowledge of how these things actually worked at more than a superficial level, they would have realized their error (or maybe succeeded!).
Note that this is a completely orthogonal problem to the use of modularity and abstractions. Abstractions are how we’re able to be more productive engineers, by allowing us to spend less time worrying about the details.
But it doesn’t allow us to ignore the details completely. The Joel on Software link argues this reasonably well (though some of the examples are dated). But in any case, I’m sure any engineer is familiar with cases where their tools (whether a compiler, or API, or OS, or otherwise) break down. That’s the leaky abstraction and nothing is immune to it. Junior engineers may throw up their hands and pass the problem onto someone else. Engineers with broader knowledge of the stack of abstractions are better able to solve these issues, either by fixing them directly in the lower layers, or finding the correct workaround.
