Title text: Update: It turns out the cannon has a motorized base, and can make holes just fine using the barrel itself as a battering ram. But due to design constraints it won't work without a projectile loaded in, so we still need those drills.

I expect this will get a lot of "Yep! That happens." replies. I'm hoping some of them will have stories to tell.

Can someone explain this xkcd better than explainxkcd? I get the obvious general gist of one programmer putting a lot of delicate work into a finely crafted tool and the other one just belt-feeding that into his shotgun approach with no regard for what it could do if used properly, but I'm struggling to think of a concrete example scenario of something like this happening in practice.

Pfhorrest wrote:Can someone explain this xkcd better than explainxkcd? I get the obvious general gist of one programmer putting a lot of delicate work into a finely crafted tool and the other one just belt-feeding that into his shotgun approach with no regard for what it could do if used properly, but I'm struggling to think of a concrete example scenario of something like this happening in practice.

How about the concept of the GUI instead of command line. That was a beautiful and powerful idea that has since been bastardized by GUIs that are difficult to use and interface. Think MS Word.

All too often, a lot of time and effort is spent making the individual components assuming they are supposed to work together to solve a problem, without taking a step back and looking at the big picture and realizing that there are simpler ways of solving the problem as a whole. Alternatively, a lot of time is spent taking previously and/or separately designed components and getting them to work together in ways that neither component was originally designed to work.In this example a couple of simpler solutions would be to just pay someone the minimum wage to drill 500 holes using a standard off-the-shelf drill (you could pay multiple people to do it if you wanted it done faster); or if you are investing the time in robotics, just have a single robot with drill which can drill all 500 holes.

Now there may be reasons why building 500 drill robots and firing them at the wall using a custom cannon may be worthwhile, if you expected to drill 500 holes in more than just the one wall (enough to justify the effort in designing and producing either of these automatic solutions over the manual solution) and/or if the drill robots were really easy/cheap to produce and load into said cannon and said system was cheaper/easier to design and set up than the single robot. Another reason could be constraints on the amount of time spent drilling the holes such that drilling all 500 holes at the same time provides significant benefit (additional compensation).

a couple of realistic analogies to the comic would be the use of provided frameworks which still require custom modules to work fully, setting things up to run in parallel in order to shorten the total time, taking that to the extreme with GPU processing (apply this function to all 1000 data points at the same time). The title text suggests that the framework was updated in such a way that instead of being able to do 90% of the work, it can now do 99% of the work, but still requires the custom module for that last 1% (and even then doesn't use really any of the functionality provided by the custom module).

see also: https://www.xkcd.com/974/, https://xkcd.com/1205/ (all too often software devs will spend longer than the recommendations here designing and working out ideal and performant solutions that don't end up saving them the time they spent on the automated solution), and then https://xkcd.com/1319/ for how much time is spent after-the-fact on keeping the automated solution working.

airdrik wrote:All too often, a lot of time and effort is spent making the individual components assuming they are supposed to work together to solve a problem, without taking a step back and looking at the big picture and realizing that there are simpler ways of solving the problem as a whole.

Spoiler:

Alternatively, a lot of time is spent taking previously and/or separately designed components and getting them to work together in ways that neither component was originally designed to work.In this example a couple of simpler solutions would be to just pay someone the minimum wage to drill 500 holes using a standard off-the-shelf drill (you could pay multiple people to do it if you wanted it done faster); or if you are investing the time in robotics, just have a single robot with drill which can drill all 500 holes.

Now there may be reasons why building 500 drill robots and firing them at the wall using a custom cannon may be worthwhile, if you expected to drill 500 holes in more than just the one wall (enough to justify the effort in designing and producing either of these automatic solutions over the manual solution) and/or if the drill robots were really easy/cheap to produce and load into said cannon and said system was cheaper/easier to design and set up than the single robot. Another reason could be constraints on the amount of time spent drilling the holes such that drilling all 500 holes at the same time provides significant benefit (additional compensation).

a couple of realistic analogies to the comic would be the use of provided frameworks which still require custom modules to work fully, setting things up to run in parallel in order to shorten the total time, taking that to the extreme with GPU processing (apply this function to all 1000 data points at the same time). The title text suggests that the framework was updated in such a way that instead of being able to do 90% of the work, it can now do 99% of the work, but still requires the custom module for that last 1% (and even then doesn't use really any of the functionality provided by the custom module).

see also: https://www.xkcd.com/974/, https://xkcd.com/1205/ (all too often software devs will spend longer than the recommendations here designing and working out ideal and performant solutions that don't end up saving them the time they spent on the automated solution), and then https://xkcd.com/1319/ for how much time is spent after-the-fact on keeping the automated solution working.

That was a remarkably coherent explanation.

Remarkable in how much sense it made to me on the first read and how well it explained the comic in a way I understood immediately. I didn't take the time to investigate if the coherency itself is remarkable in relation to your post history, but I trust it's par for the course.

It almost works as an analogy for some other things, too, in that one person's put a lot of thought and work into making something that'll do the job beautifully and then it's getting handed to someone who doesn't give a fig, like using the graphics card as a doorstop or the CPU heatsink as a bootscraper, handing a sniper rifle to a generic squaddie who still thinks, deep down, it'll hurt more if he pulls the trigger harder or going to all that trouble to get a studio album recorded with all the component tracks blended at exactly the right levels to sound the way it's *meant* to sound when it's played through a decent sound system and building a really *good* sound system that, with four button-presses, could play that album perfectly ... then having some clown shove the bass boost all the way to maximum because all he wants for Christmas is ruptured eardrums.

Brilliand wrote:I expect this will get a lot of "Yep! That happens." replies. I'm hoping some of them will have stories to tell.

Sort of, but not (in my experience) the way shown in the comic. What has a bad habit of happening is that an initialdesign is laid out, and various teams/people are assigned a piece of it. Then, there is little to no coordination betweenthe groups during development, and when integration time comes, it winds up like

I read it differently than the other explanations of the comic I've seen so far.

The team was given a requirement: Make 500 holes in a wall. Left Engineer spent a lot of time and effort designing a tool that was specialized for the manual method of making holes in walls. Right Engineer built an autoloading(?) cannon which was specialized for... another method of making holes in walls. This gives two partial solutions to the problem that are nearly complete on their own, but have significant incompatibilities in approach that make it inefficient to combine them into a complete solution. But, coincidental properties of the fancy drill make it technically suitable for misuse as a cannon projectile.

In "real engineering", the expense of manufacturing another 499 fancy drills means using the drills as cannon ammunition is too absurd even for a government contractor. But, in software, this kind of duplication is so cheap, this forum post was duplicated over a dozen times on its way from my computer to yours. And so (for example) you can end up with dozens of instances of Jenkins on a single server, each with its own preallocated 512MB heap, just to handle a few dozen slightly different variants of "run a previously-configured command and tell me if it succeeded". This is a total waste of Jenkins' capabilities and of precious RAM... but Jenkins can technically fill that role...

Brilliand wrote:I expect this will get a lot of "Yep! That happens." replies. I'm hoping some of them will have stories to tell.

Sort of, but not (in my experience) the way shown in the comic. What has a bad habit of happening is that an initialdesign is laid out, and various teams/people are assigned a piece of it. Then, there is little to no coordination betweenthe groups during development, and when integration time comes, it winds up like

Or like Microsoft Office. I still can't fathom how it is that Powerpoint supports CTRL-Q but no other Office app does, or that wildcards in search boxes are different from Word to Excel, or the total mess that Newline and CarriageReturn become when copypasting between apps.

Heimhenge wrote:How about the concept of the GUI instead of command line. That was a beautiful and powerful idea that has since been bastardized by GUIs that are difficult to use and interface. Think MS Word.

I don't get command-line fetishism / GUI bashing. MS Word is hard to use? What alternatives have similar capabilities but are easier to use?

And don't get me started on command-line debuggers. You can pry my IDEs and ddd from my cold, dead hands.

GlassHouses wrote:I don't get command-line fetishism / GUI bashing. MS Word is hard to use? What alternatives have similar capabilities but are easier to use?

Earlier versions of Word, before "Ribbons".

I have used more GUI environments than most people can name US presidents. I write a new widget toolkit twice each day before breakfast. I can recite the entire HIG forwards and backwards in a single continuous belch. Yet, any time I sit down at my fiancee's computer and try to do anything in a modern Office app, I'm totally helpless and she has to rescue me.

GlassHouses wrote:And don't get me started on command-line debuggers. You can pry my IDEs and ddd from my cold, dead hands.

I use weird languages / environments often enough that I just stopped counting on having a debugger at all. Which is a problem when I'm using a language for which a perfectly good debugger exists (i.e. pretty much all of them), and I can't stop myself from just adding printfs and recompiling.

Solra Bizna wrote:Yet, any time I sit down at my fiancee's computer and try to do anything in a modern Office app, I'm totally helpless and she has to rescue me.

Most of the time, I find the old 'via menu' keyboard shortcut still works, behind the scenes, which I can use intuitively through muscle-memory. "Alt-D(ata) S(ort)", for example, is easier to type than grabbing the mouse anew and trying to hunt down the ribbon icon used in the immediate version of Excel (or in Libre/OpenOffice's Calc, which is also nicely compatible with the more honest GUI setup of past Offices!). That's aside from official shortcuts like Ctrl-S (and Shift-Ctrl-S) for Save (and Save As) in one single multikey stab. Though I'd have to sit myself down at a keyboard and ghost their use to recall what half of them are if I'm ever asked to reveal the combos concerned!

Am I the only one who thinks that drill guy is the one in the wrong here? My experience as a software engineer has been seeing far too much time wasted building fancy tools and options that no one wants or needs. All he had to do was build a cannonball and he could have moved on to the next project.

The funny part is that cannon guy has the exact right solution - given the work done so far, his plan minimizes the remaining work.

Let's have a fervent argument, mostly over semantics, where we all claim the burden of proof is on the other side!

MartianInvader wrote:Am I the only one who thinks that drill guy is the one in the wrong here? My experience as a software engineer has been seeing far too much time wasted building fancy tools and options that no one wants or needs. All he had to do was build a cannonball and he could have moved on to the next project.

The funny part is that cannon guy has the exact right solution - given the work done so far, his plan minimizes the remaining work.

No, you're not the only one. One of the many pitfalls of our trade is falling prey to YAGNI, the god of you'll never know but adding X, Y and Z just might come in handy some day (except that it nearly always doesn't). That drill sounds like it would be a wonder to operate (I'm sure a sufficiently advanced idiot could be found who manages to misuse it and drill bad holes with it anyway). Of course it took him an extra 5 months to add all of the fancy robotics, gears and whatnot, but that's ok because it took at least that long to (over)design the cannon (though both could have been done so much sooner if they'd just stuck to the original simplistic designs).

Sableagle wrote:Without knowing the specs of the wall and the holes they need in it, I can't say for sure that a Wingmaster and 20 rounds of #4 buckshot wouldn't have had the job done inside 2 minutes.

We can't trust third-party libraries! Better to build something in-house so we have control of it.

Let's have a fervent argument, mostly over semantics, where we all claim the burden of proof is on the other side!

MartianInvader wrote:Am I the only one who thinks that drill guy is the one in the wrong here? My experience as a software engineer has been seeing far too much time wasted building fancy tools and options that no one wants or needs. All he had to do was build a cannonball and he could have moved on to the next project.

The funny part is that cannon guy has the exact right solution - given the work done so far, his plan minimizes the remaining work.

That may be the case, or the drill guy may have built something to the exact requirements of a different customer on a different project, and now cannon guy wants to make use of existing libraries that appear to meet his needs.

MartianInvader wrote:Am I the only one who thinks that drill guy is the one in the wrong here? My experience as a software engineer has been seeing far too much time wasted building fancy tools and options that no one wants or needs. All he had to do was build a cannonball and he could have moved on to the next project.

The funny part is that cannon guy has the exact right solution - given the work done so far, his plan minimizes the remaining work.

That may be the case, or the drill guy may have built something to the exact requirements of a different customer on a different project, and now cannon guy wants to make use of existing libraries that appear to meet his needs.

Heimhenge wrote:How about the concept of the GUI instead of command line. That was a beautiful and powerful idea that has since been bastardized by GUIs that are difficult to use and interface. Think MS Word.

I don't get command-line fetishism / GUI bashing. MS Word is hard to use? What alternatives have similar capabilities but are easier to use?

KLyx. Or libreoffice.

And don't get me started on command-line debuggers. You can pry my IDEs and ddd from my cold, dead hands.

I best liked the Turbo Pascal debugger. I'm still using jstar (a mode of the joe editor) because it's like the Turbo Pascal editor.

Solra Bizna wrote:I read it differently than the other explanations of the comic I've seen so far.

...

In "real engineering", the expense of manufacturing another 499 fancy drills means using the drills as cannon ammunition is too absurd even for a government contractor. But, in software, this kind of duplication is so cheap, this forum post was duplicated over a dozen times on its way from my computer to yours. And so (for example) you can end up with dozens of instances of Jenkins on a single server, each with its own preallocated 512MB heap, just to handle a few dozen slightly different variants of "run a previously-configured command and tell me if it succeeded". This is a total waste of Jenkins' capabilities and of precious RAM... but Jenkins can technically fill that role...

Developers bolting their own permissions/role based access control onto PostgreSQL is another example. (Yes, I've seen it done in a mainstream production application that could have just used PostgreSQL roles directly.)

Creating a Kubernetes cluster on a fleet of VMs in VMSphere and managing the PODs on every node and the containers in every POD is usually another example. It's really, really cool that you can do it. But do you NEED to do it? Almost certainly not.

As one final example, consider people who do quick mathematical calculations using Google search. Just think about that for a good long time. If it doesn't strike you as absurd, you're probably not a programmer. (NB: It's perfectly fine that Google makes this functionality available to its users. It's completely absurd that people use it.)

Wildcard wrote:As one final example, consider people who do quick mathematical calculations using Google search. Just think about that for a good long time. If it doesn't strike you as absurd, you're probably not a programmer. (NB: It's perfectly fine that Google makes this functionality available to its users. It's completely absurd that people use it.)

Hey, if it's the one time this decade I'm going to want to multiply the current price per Troy ounce of gold by the kinetic energy of 1 Troy ounce at 0.5c and divide that by 2.7 times the sum of the price of 2/13 of a gram of caster sugar and the price of 11/13 of a gram of ammonium nitrate to find out how efficient the accelerator needs to be to justify firing gold bullets at a thing rather than blowing it up the old-fashioned way, the Google search bar is fine.

Sableagle wrote:Hey, if it's the one time this decade I'm going to want to multiply the current price per Troy ounce of gold by the kinetic energy of 1 Troy ounce at 0.5c and divide that by 2.7 times the sum of the price of 2/13 of a gram of caster sugar and the price of 11/13 of a gram of ammonium nitrate to find out how efficient the accelerator needs to be to justify firing gold bullets at a thing rather than blowing it up the old-fashioned way, the Google search bar is fine.

Fine, but how about a quick 8 term multiplication and/or addition problem of 3 digit numbers? Let's send it over the network to Mountain View!

Wildcard wrote:As one final example, consider people who do quick mathematical calculations using Google search. Just think about that for a good long time. If it doesn't strike you as absurd, you're probably not a programmer. (NB: It's perfectly fine that Google makes this functionality available to its users. It's completely absurd that people use it.)

That use I'd actually defend. For a one-off calculation, the overhead of using Google is likely smaller than the overhead of firing up a calculator app, especially when just doing “Ctrl+L, = 1 + (2/3)”.

This gets even more obvious when features going beyond numeric arithmetics are used. E.g.

16 usd in eur. Doing it in a different way would likely involve looking up the current rates, which is undesirable overhead and would likely end up using more search queries.

= (boltzmann constant) * 300 Kelvin / (electron volt). At best, I'd have the constants pinned to the Wall, but even just typing them in would still be more overhead then doing the google query and open me up for unnoticed typos. If I have to look them up, I'd either have a huge overhead from fetching a book, or look it up via Google or Wikipedia, resulting in even more queries. For more complex expressions, I'll also want the feedback about the output units, in order to avoid easily made mistakes during unit conversion, or as an additional check that I was working with the dimensions I thought I was. At this point I'd have to read API documentations, and all that for a single one-off query, that I could have done in seconds with Google. For more complex stuff I use Wolfram Alpha though, as it provides useful complementary output and understands common abbreviations (e.g. k_B * 300K / eV).

x7eggert wrote:

GlassHouses wrote:

Heimhenge wrote:How about the concept of the GUI instead of command line. That was a beautiful and powerful idea that has since been bastardized by GUIs that are difficult to use and interface. Think MS Word.

I don't get command-line fetishism / GUI bashing. MS Word is hard to use? What alternatives have similar capabilities but are easier to use?

KLyx. Or libreoffice.

Isn't KLyx basically a woefully outdated version of LyX? I can pretty much embrace LyX and LaTeX as superior alternatives to most office solutions for complex texts (papers, thesis), though for smaller, formatting-heavy things like Letters I prefer Word.

As for Libreoffice... Equation support is a mess, default templates look much worse than in Office (translates into extra work), and Impress... Among Lyx, Latex, Powerpoint and Impress I'll choose anything over Impress. Lyx/LaTeX for the superior structuring tools, Powerpoint for the ability to quickly create reasonably-looking slides and, if the audience is so inclined, SmartArt. Impress has neither, sadly, though it shares the Powerpoint advantages of slide-sorter and the ability to hide slides from the presentations, while still allowing to bring them up quickly if needed.

Ultimately, monolithic office suits probably just don't play to the strengths of open source.