Difference between revisions of "2021: Software Development"

Explain xkcd: It's 'cause you're dumb.
Jump to: navigation, search
(Transcript: Do NOT delete this tag too soon.)
(Transcript)
Line 18: Line 18:
 
==Transcript==
 
==Transcript==
 
{{incomplete transcript|Do NOT delete this tag too soon.}}
 
{{incomplete transcript|Do NOT delete this tag too soon.}}
'''[[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.
+
:[Cueball and Hairy are standing together and Hairy holds a robot like device 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.
  
'''[[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
'''Caption:''' How Software Development Works
 
  
 
{{comic discussion}}
 
{{comic discussion}}

Revision as of 16:03, 18 July 2018

Software Development
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.
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

Ambox notice.png This explanation may be incomplete or incorrect: Created by an AUTOMATIC DRILL CANNON - Please change this comment when editing this page. Do NOT delete this tag too soon.
If you can address this issue, please edit the page! Thanks.

Software development is characterized by a lot of back and forth on requirements. Here, the requirement is to drill 500 holes in a wall. The software engineer (Cueball) has created a precision drill (some elegant software). As soon as he hands it off to Operations (Hairy), it gets deployed to the wall 500 times via a cannon. Part of the joke here is that they are making holes with drills by using them as bullets, rather than as, say for example, drills.

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

The title text is a joke about how often in software the best solution to a problem is a general one, rather than a specific one. 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.

Transcript

Ambox notice.png This transcript is incomplete. Please help editing it! Thanks.
[Cueball and Hairy are standing together and Hairy holds a robot like device 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


comment.png add a comment! ⋅ comment.png add a topic (use sparingly)! ⋅ Icons-mini-action refresh blue.gif 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)