Editing 2797: Actual Progress

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 10: Line 10:
  
 
==Explanation==
 
==Explanation==
 +
{{incomplete|Created by a CONFUSED RESEARCHER - Please change this comment when editing this page. Do NOT delete this tag too soon.}}
  
 
An edge case is a situation, often in software engineering but also in other domains, that is rare and may need special handling and does not perform the way most of the situations do.
 
An edge case is a situation, often in software engineering but also in other domains, that is rare and may need special handling and does not perform the way most of the situations do.
Line 15: Line 16:
 
At the start of tackling a complex problem, somebody may come up with a simplified interpretation of it, see it as simple, and implement and even deploy a system that uses their interpretation. These partial (incorrect) and ingeniously useful solutions are called heuristics in software engineering. If the developer is unaware that their formation of the problem is incorrect, they may happily dive into edge cases hoping to hash them out and resolve them, only to uncover that the very underpinnings of their possibly-live system are based on false perceptions or logic and then often even be at a loss as to how it is working at all.
 
At the start of tackling a complex problem, somebody may come up with a simplified interpretation of it, see it as simple, and implement and even deploy a system that uses their interpretation. These partial (incorrect) and ingeniously useful solutions are called heuristics in software engineering. If the developer is unaware that their formation of the problem is incorrect, they may happily dive into edge cases hoping to hash them out and resolve them, only to uncover that the very underpinnings of their possibly-live system are based on false perceptions or logic and then often even be at a loss as to how it is working at all.
  
Similar issues can arise in the physical sciences. A few pieces of experimental data, taken under novel conditions, may not fit the currently-accepted model. Attempts to reconcile them may lead to the discovery that many other pieces of data, which previously had been taken to confirm that model, lead to problems when they are examined carefully. Ultimately, a better, more generally applicable model may be found. For example, Mercury's orbit isn't consistent with strictly Newtonian mechanics, a problem that resulted in many theories but which was ultimately resolved by Einstein's Theory of General Relativity. Extremely careful measurements of other planets' orbits would have revealed that they, too, don't conform to Newtonian mechanics; the effect is general, but most easily observed with Mercury because of its relative proximity to the sun. (More commonly, the few pieces of data that don't fit may be found to be invalid, a result of experimental error under the novel conditions. "They laughed at Galileo... but they also laughed at Bozo the Clown.")
+
At this point it may be the case that the developer is actually working on a cutting-edge research challenge, unaware that this is the case, and the problem space they have to grapple with is one the largest minds in the world have still not solved. (there’s an xkcd from long ago where a naive boss asks an engineer to perform a simple task and the engineer gives a short timespan, and then the naive boss asks the engineer to perform a novel research task, and the engineer asks for a research team a long timespan, that could be cited here) Before the easy accessibility of research papers it was much less obvious when or when not this was happening. And today, when many historically very hard problems have many more well-known solutions, and many of the very hard problems that have been intractable in the past are demonstrating aggressive progress that anyone can step in and review, the situation is quite different and much more tangible.
  
At this point it may be the case that the developer is actually working on a cutting-edge research challenge, unaware that this is the case, and the problem space they have to grapple with is one that is actively being worked on, yet nobody has yet completely addressed. In [[1425: Tasks]], a naive boss asks an engineer to perform two tasks that the engineer gives wildly different estimates for the developmental timespan. Before the easy accessibility of research papers it was much less obvious when this was or was not happening. And today, when many historically very hard problems have many more well-known solutions, and many of the very hard problems that have been intractable in the past are demonstrating aggressive progress that anyone can step in and review, the situation is quite different and much more tangible.
+
Another quite common software engineering situation in which the situation in the comic can happen is when working with a codebase that has been rushed to market without organizing and modeling its underlying concepts well: “spaghetti code”. At first one may think they can enter the software and simply patch a fix, but past similar patches have made the parts needlessly intertwined and baked any heuristics in in an unmaintainable way.
  
Another quite common software engineering situation like the comic is when working with a codebase that has been rushed to market without organizing and modeling its underlying concepts well: “spaghetti code”. At first one may think they can enter the software and simply patch a fix, but past similar patches have made the parts needlessly intertwined and baked any heuristics in in an unmaintainable way.
+
==Transcript==
 +
{{incomplete transcript|Do NOT delete this tag too soon.}}
  
The joke regarding “actual progress” is both sarcastic and possibly referring to how the most progress is made on a problem when its general structure and underpinnings are addressed directly: when it is better understood and its root causes engaged. This appears ironic when it means breaking apart the solution to unusability before rebuilding a better one, which is usually what happens here; this is called refactoring and is analogous to taking everything off the shelves of a slightly-messy room, making it very messy, before putting everything back in a new mess-free organization. In both situations if your new solution has a crucial mistake you end up with a much worse situation.
 
 
The title is similar to [[1906: Making Progress]] which shares a similar structure of "I Started... But now, After..." but ends up with problems listed in a spreadsheet rather than more confusion.
 
 
The title text may have been partially inspired by the PBS Spacetime episode [https://www.youtube.com/watch?v=TbzZIMQC6vk "Did AI Prove Our Proton Model WRONG?"] released twelve days before this comic, which discusses how physicists don't have a proven accurate model for the internal structure of a proton at rest and that having an AI analyze collision data resulted in a model significantly different from human-made ones.
 
 
==Transcript==
 
 
:[Cueball is sitting on an office chair at a desk and has his hand on a laptop. Ponytail is standing behind him.]
 
:[Cueball is sitting on an office chair at a desk and has his hand on a laptop. Ponytail is standing behind him.]
 
:Cueball: When I started this morning, there were a few edge cases I was confused about.
 
:Cueball: When I started this morning, there were a few edge cases I was confused about.
  
 
:[Panel of just Cueball sitting on the office chair.]
 
:[Panel of just Cueball sitting on the office chair.]
:Cueball: But now, after a full day of research,
+
:Cueball: But now after a full day of research,
  
 
:[Same scene as in the first panel, but Cueball has his hand on his lap.]
 
:[Same scene as in the first panel, but Cueball has his hand on his lap.]

Please note that all contributions to explain xkcd may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see explain xkcd:Copyrights for details). Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:

Cancel | Editing help (opens in new window)