Software Feature Entropy Cycles - Part 2, Example

I figured I might need to provide some concrete elaboration on my previous post about "Software Feature Entropy Cycles", so here goes.

Back in the late 1980's, while working for a "Naval Architecture and Engineering Firm", I began my career as a programmer.  According to my IRS tax return, my job was "Senior Engineer Technician", which was basically a glorified drafter, who also does some calculations.  My real job was writing tons and tons of LISP code for AutoCAD R10 and R11, and eventually R12 and onward, to automate design processes for piping and HVAC systems on U.S. Navy warships.

One of the interesting aspects about the world of CAD is that every niche industry has evolved its own unique "standards" of design and drafting.  From sheet borders, to dimensions and callouts, to tables and lists, to fonts and font sizes, to colors and layers.  You name it, I've seen every bizarre permutation of "standards" you can imagine. Metric vs. Standard. All Modelspace vs. Modelspace/Paperspace vs. all Paperspace.  Microscale and Macroscale.  Orthographic and Isometric and Oblique and Perspective, and whatever.

Some of the "standards" required for U.S. Naval design drawings were "NEVER CROSS CALLOUT LEADERS" and "NEVER CROSS A DIMENSION FEATURE WITH A CALLOUT LEADER".  Of course, in reality that wasn't always possible.  Some drawings contains such complicated spewage of goo (technical term for tons and tons of shit, making the end result difficult to read and make sense of), so breaking those "rules" was not only hard to avoid, it was downright required.

So, myself and another (much better) programmer, named Brad, went to work making some LISP routines to automatically detect when a Leader crossed another Leader or Dimension and automatically broke out a "gap" at the intersection.  Later versions of AutoCAD actually supported "real" LEADER entities, and also added the GROUP entity, so we updated our code to break the leader, remove the arrow head from the label leg, and applied both parts into a single GROUP entity to retain some behavioral integrity.  It worked pretty well actually.

Then Autodesk released "Bonus Tools", later renamed as "Express Tools", which included a leader gap feature that worked as well as ours, maybe better.  So we deprecated our code and moved on.  This is a fairly typical iterative process for most developers:  As the base product/technology/platform gains new features which previously required custom extensions, those custom extensions become unnecessary and deprecated.  Remaining feature "gaps" continue to be filled by custom extensions (aka program code), and newly-identified gaps are addressed with new extensions, and the cycle continues.

That's a pretty simple, yet concise example of a Software Feature Entropy Cycle.