Reply to post: Do-over

Java EE renamed 'Jakarta EE' after Big Red brand spat

Milton Silver badge

Do-over

Kevin McMurtrie wrote: "... It lived through the "abstract the abstractions" darks days so it has factories for factories and objects so completely abstracted that they must claim to do nothing at all ..."

—and provided a ghastly reminder of some horrifying modern coding habits. I know of people—who were never particularly good coders, but always imagined that they were brilliant—who, if poorly managed (i.e. working for an English-speaking Anglo-Saxon company), would choose to find work they liked rather than what the business really neded to be done. That work would ofttimes be trivial cosmetic stuff that had neither importance nor urgency. Sometimes it would be trivial exercises like writing reports for the business users—which the latter were supposed to be doing themselves already.

But, when denied these opportunities to squander their (often quite generous) salaries on needless tasks, they would turn to the wealth of make-work offered by Abstraction. A piece of code, an API, a service, some kind of interface, anything at all really, would be targeted for "improvement" and, before you know it, something that had worked perfectly well for months or years would abruptly vanish behind another layer of calls, wrappers, settings, interface addresses, logins, authentications and wotnot. Pompous emails would arrive informing us that such-and-such had been "deprecated" and that a "refactored"¹ or even "new" version must be used (causing 27 other systems to require changes to preserve interoperability), citing mysterious enhancements and improvements which, even if no immediate advantage could be discerned, would make the business ready for whatever IT-BS-phrases would be fashionable next year.

No useful additional functionality would appear; sometimes it would disappear; new bugs would emerge; everything would now take a little longer, dramatically so if a cluster of witlessly recurring and poorly tested "checks" were included; here and there would be plastered long and important-sounding new names and labels for things; release notes—lacking important, pertinent information—would nonetheless feature the author's name and assorted samples of the current buzzword drivel thus "cloud-enabled", "AI-compatible" with "high-volume messaging potential" and "enhanced security".

You end up with endless layers of utterly valueless complexity, as abstractions of wrappers conceal layers of indirection of wrappers in thickets hiding jungles of abstractions of code wrapped in wrapstractolayers. Sometimes the only bit that was well-written, after you'd churned through 39,231 lines of wrapping, was the original 207 lines of core code.

Observing this behaviour (in other people's teams, I promise you) I went through various stages of disbelief, disgust and even anger, but eventually came to understand this by a simple analogy.

Bad coders, under-tasked, under-trained and under-managed, gravitate to pissing on things ... just like dogs. "Look how important and clever I am: I just peed here!" It really does seem to be that simple. (And explains some other habits of mediocre male coders.)

¹ My term for this process, now cautiously adopted by those unfortunate enough to have worked with me, is "refucktoring". As in, "Chris refucktored the code for SystemTwo and now it keeps barfing".

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019