The upcoming issue of the SICPers newsletter is all about phrases that were introduced to computing to mean one thing, but seem to get used in practice to mean another. This annoys purists, pedants, and historians: it also annoys the kind of software engineer who dives into the literature to see how ideas were discussed and used and finds that the discussions and usages were about something entirely different.
So should we just abandon all technical terminology in computing? Maybe. Here’s an irreverent guide.
Luckily the industry doesn’t really use this term any more so we can ignore the changed meaning. The small club of people who still care can use it correctly, everybody else can carry on not using it. Just be aware when diving through the history books that it might mean “extreme late binding of all things” or it might mean “modules, but using the word class” depending on the age of the text.
Nope, this one’s in the bin, I’m afraid. It used to mean “not waterfall” and now means “waterfall with a status meeting every day and an internal demo every two weeks”. We have to find a new way to discuss the idea that maybe we focus on the working software and not on the organisational bureaucracy, and that way does not involve the word…
If you can hire a “DevOps engineer” to fulfil a specific role on a software team then we have all lost at using the phrase DevOps.
This one used to mean “psychologist/neuroscientist developing computer models to understand how intelligence works” and now means “an algorithm pushed to production by a programmer who doesn’t understand it”. But there is a potential for confusion with the minor but common usage “actually a collection of if statements but last I checked AI wasn’t a protected term” which you have to be aware of. Probably OK, in fact you should use it more in your next grant bid.
Previously something very specific used in the context of financial technology development. Now means whatever anybody needs it to mean if they want their product owner to let them do some hobbyist programming on their line-of-business software, or else. Can definitely be retired.
Was originally the idea that maybe the things your software does should depend on the things the customers want it to do. Now means automated tests with some particular syntax. We need a different term to suggest that maybe the things your software does should depend on the things the customers want it to do, but I think we can carry on using BDD in the “I wrote some tests at some point!” sense.
Reasoning About Software
Definitely another one for the bin. If Tony Hoare were not alive today he would be turning in his grave.
Technical Debt is useful for programmers translate a short term business decision’s effect on the system they are working on. It’s not for programmers alone, that can be done many different ways.
The only way I will let go of “Technical Debt” is with a replacement that is just as hard-hitting.
For example, “If you want this feature live by tomorrow, we will have to implement a number of hacks that will create technical debt we will have to pay back later. If we can have a week to implement this feature, then we won’t have any technical debt to clean up and payback later as we will have the time to set this feature up properly”
I can’t think of a more clear summation than “technical debt” when talking to a non-programmer.
I concur with the need dropping the modern interpretation of agile. In your point of view, what is a better way to talk about “writing software”?
Another term I propose is “transparent”.
One never knows whether you can “see through” it and understand what in detail is going on (the literal use), or whether it is just as “you don’t need to know how, but it’ll just work.” (computer science jargon use).