2021: Software Development

|< < Prev Comic #2021 (July 18, 2018) Next > >|

Software Development

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.

Explanation

Software development is often characterized by graceless solutions to rudimentary problems. Cueball has built an elegant drill (function) that can adjust torque and speed as necessary automatically to fulfill his requirement of 500 holes in the wall. Hairy, in a categorically inelegant solution, loads 500 drills into a cannon and shoots them at the wall. This solution, in reality, would entail too many ludicrous safety problems to execute, but in software, the implications are only really bad code.

The casual disregard for the software itself is reminiscent of the idea of cattle not pets when deploying to servers.

This resembles assigning two different software teams to resolve different parts of a problem and of making the independent tools collaborate to form a fluid solution. The so-called "drill team" is given the task of making the part of the system that makes a hole in the wall. The cannon team was given the task of making the part of the system that aims what the drill team produces at the designated place on the wall and subsequently drills the hole. The drill team assumed that the aiming device would merely position their portion on the wall allowing it to make the hole, but the cannon team could not make assumptions about how the drill team would generate holes - they needed to make something that could use whatever the drill team produced to make the holes, thus making a cannon, so they could ensure their success.

The title text is a joke about how often in software the best solution to a problem is general rather than specific. See for example developers using Ruby on Rails (a full web framework with support for emails, templating, and web sockets) for a simple API-only service. They only need a very small part of rails (the hole drilling part), but end up with the whole framework anyway due to design limitations.

Another explanation of the title text is that software development is also often characterized by complexity and unintentional interdependence between different modules of code. It is an unending source of frustration for coders that a seemingly minor change to code can cause major changes to how the program works, including changes seemingly unrelated to the specific code that changed. A similar problem is when a line of code that “should be” unnecessary (according to the rules of the programming language) ends up being essential because the program will not work if the code is cleaned up and the line removed. A final factor is that coders often write a particular function once in the first module, and then call back to that function when necessary in subsequent modules rather than rewriting the function over and over again. In that case, the first module cannot be eliminated, even if it is no longer necessary, because then all of the calls to the original function would be null, and the rest of the modules could not work. This can happen not just within programs but across them, as much software on the internet relies on large collections of program modules in public or open source software databases. When a module goes missing it can have wide ranging effects, as seen in March of 2016.

In the context of the comic, it could be that the code for the cannon was written to check if it is “loaded” before it does anything, so the drill code is still needed to get the cannon to move on its motorized base and make the holes. Or the code for the drill defines an obscure variable that is used by other code for the cannon or its base, so “removing” the drill code would cause the cannon to “crash” and not operate.

Transcript

[Cueball and Hairy are standing together and Hairy holds a power tool in his hands.]

Cueball: We need to make 500 holes in that wall, so I've built this automatic drill. It uses elegant precision gears to continually adjust its torque and speed as needed.

Hairy: Great, it's the perfect weight! We'll load 500 of them into the cannon we made and shoot them at the wall.

[Caption below the frame:]

How software development works

 add a comment! ⋅  add a topic (use sparingly)! ⋅  refresh comments!

Discussion

It seems to me that the cannon is a metaphor for powerful hardware. The drill is a metaphor for elegant and efficient code. The computer is so powerful that the fact that the elegance or efficiency of the code is irrelevant to how it is actually used.Zeimusu (talk) 15:48, 18 July 2018 (UTC)

Hi, first time posting ;) To me it seems that the Title text is an example how after some time and many updates the original solution becomes some kind of abomination. Used in abstruse ways for something it was never intended for just because it works and is a quick and simple fix. After some time one always ends up doing unnecessary and arbitrary things in order to get what you actually wanted to achive. Like loading projectiles into a cannon just to use it as a battering ram. 162.158.91.137 (talk) (please sign your comments with ~~~~)

Agreed. The current rush to monetize distributed crypto-token ledgers smacks of this to me. Rather than focus on refining the protocols involved (which is hard) many projects seem to focus merely on implementing the protocols in any half-@$$ed way that appears legitimate enough on the surface to attract investment capital & turn a profit for some insider. ProphetZarquon (talk) 16:49, 20 July 2018 (UTC)

Don't forget the fact that no one wants to figure out how to use the elegant drill, but instead use it for its most obvious if least elegant piece--the stationary pointy bit. -Todd 7/18/2018 17:32 UTC 172.69.69.88 (talk) (please sign your comments with ~~~~)

The way I understand this, Hairy had the cannon done already to make holes in the wall, the typical brute force solution to the problem. But he needed ammo of a certain weight and gave that task to Cueball. Cueball then made a drill, an elegant solution that would do the job better than the canon. Hairy sees the drill and doesn't care about all the fancy functions, all he needed was an object of the proper weight to put 500 of them in the already built cannon. In programming, this shows either a reluctance from Hairy to adapt to the better solution and insist on using the brute force approach. Or, it shows how often programmers tend to make things way more complicated than is needed. Cueball went to remake a new solution for the problem when all he was supposed to do was make a cannonball of the proper weight.-Vince23 17:46, 18 July 2018 (UTC) -- Vince23 (talk) (please sign your comments with ~~~~)

This also shows the results of not clearly defining terms. Cueball interpreted 'drill' to mean 'a hand held drilling machine' whilst Hairy toolkit to mean a 'drill bit'. So when Cueball delivers his component, Hairy just uses it as a 'dumb' piece of ammo. RIIW - Ponder it (talk) 22:31, 18 July 2018 (UTC)

I have a slightly different take. You develop a tool (drill or accounting application) that solves the problem. Then you develop a meta-tool (cannon or cloud-based services or Container software) that bundles simple tools and throws them at the same problem. The comic is not too effective in making the point. Rtanenbaum (talk) 14:43, 20 July 2018 (UTC)

Automatic-Drill Cannon is my new favorite impractical weapon. ProphetZarquon (talk) 01:44, 19 July 2018 (UTC)

Sorry if this is amazingly off topic, but is that an automatic-drill cannon or an automatic drill-cannon? Like a Gatling gun for power tools? -Milliways 3:38, 19 July 2018 (UTC)

Not off topic at all; It's a cannon which fires automatic drills, therefore it's an automatic-drill cannon. An automatic drill-cannon would automatically fire drills. While it's possible (especially given the motorized base) that the cannon is automatic, we know that the drill is automatic.

Nice name, by the way.

ProphetZarquon (talk) 16:41, 20 July 2018 (UTC)

An automatic drill-cannon is a thing that shoots and bores, and has an "automatic" feature. The second thing you described would be called just "automatic drill cannon", AFAIK.108.162.212.149 00:14, 29 July 2018 (UTC)

It is so fitting that this comic came out on the same day as Minecraft 1.13, an update that was incredibly rushed due to a stupid deadline. An update that contains many amazing features and code cleanups and rewrites, but also crashes, save corruptions, lots of bugs and lag, etc. An update that was meant to mainly fix bugs and clean up code, but ended up getting merged with another feature update, which caused most of this mess. Fabian42 (talk) 08:22, 19 July 2018 (UTC)

Definitely seems make more sense if you consider the person on the left to be the software developer and the person on the right to be the user, doesn't it? But equally valid if the person on the left is the hardware developer and the person on the right is the programmer. Swhitlock (talk) 18:20, 19 July 2018 (UTC)

It makes most sense if these are two software developers who each have been given part of a task, with ill defined boundaries between the parts. --162.158.134.34 06:27, 20 July 2018 (UTC)

I think it also makes sense if the left is a software developer & the right is a hardware or UX developer. [Develop innovative code process -> Ignore finer points of process -> Implement a crude solution using brute hardware power & a kludge] seems to be a pretty common scenario. Modern computers running Windows™ or Linux could be considered an example of this, as both contain brilliant snippets of code implemented in cumbersome, inelegant, or less-than-efficient ways. (Mac might do this too, but I wouldn't know.) ProphetZarquon (talk) 16:41, 20 July 2018 (UTC)

Example: Automatic drill <=> database. Cannon <=> foreach (var row in db.execQuery("select * from customer")) if (resultRow["name"] == searchTerm) return true; 141.101.77.248 23:45, 19 July 2018 (UTC)

I think that this comic represents how programmers put time above cost. Having 500 drills would be expensive but it would significantly reduce the time taken, as they are synchronous. This arguably isn't a bad tactic, but it stops programmers from worrying about cost at all in some cases.

I think this also represents front end Vs back end. If you consider the drill as the front-end and the cannon as the back end. The drill is elegant while the cannon is ugly, the same thing often happens in programming. TrueBoxGuy (talk) 13:19, 22 July 2018 (UTC)

As a back-end programmer, and with my experience with front-end developers, I certainly disagree :) Darthstark (talk) 12:23, 10 February 2023 (UTC)

Surely Drill = carefully crafted code, Cannon = docker container, with a similar sentiment to 1988? 162.158.38.82 08:19, 27 July 2018 (UTC)

Everybody is blaming Cueball for delivering the wrong thing, but we all do this all the time without thinking about it. For instance, YAML has zillions of features that nobody should ever use, but it's still preferred by some people over INI files for configuration because it can represent hierarchical data more clearly. Or how Awk is a complete programming language that could be used to write _anything_ but all anyone uses it for is as a crappy shlexer (like ... | awk '{print $4}'). If what you have is a big stockpile of drills, then it's better to just repurpose the drills for the cannon instead of going out of your way to make cannonballs. Acrisci (talk) 22:40, 30 July 2018 (UTC)