TITLE: A Gresham's Law for Software
AUTHOR: Eugene Wallingford
DATE: November 11, 2010  8:00 AM
DESC: 
-----
BODY:
Recently,
<A HREF="https://twitter.com/KentBeck/status/1836804118421504">
   Kent Beck tweeted</A>:

<BLOCKQUOTE><EM>
cleaning up junit in preparation for 4.9 release with
@dsaff. why do bad design decisions spread faster than
good ones?
</EM></BLOCKQUOTE>

I immediately thought of
<A HREF="http://en.wikipedia.org/wiki/Gresham's_law">
   Gresham's Law</A>
from economics, which is commonly expressed as "bad money
drives good money out of circulation".  That sounds like
what Kent is saying: bad design decisions drive good ones
out of our code.

In reality, the two ideas are not alike.  Gresham's Law
refers to a human behavior we can all understand.
Suppose we have two coins denominated as a worth one
dollar.  The first coin is made of gold, a rare metal
of enduring social and economic value.  The second is
made of nickel, a common metal not valued by the people
using the coins.  Under these conditions, people will
tend to hoard the gold coins and use the nickel coins
in trade.  The result is that, eventually, there will
be few or no gold coins in circulation.  Hence the
aphorism: "bad money drives good money out of
circulation".

(Sir Thomas Gresham, a financial agent at the time of
Queen Elizabeth I, was not the first person to note
this behavior.  According to
<A HREF="http://en.wikipedia.org/wiki/Gresham's_law">
   Wikipedia</A>,
Aristophanes remarked on the phenomenon in his play
"The Frogs", at the end of the 5th century BC.)

That's not what is happening in JUnit or other
software systems.  Kent and his partners aren't
hoarding good design decisions and using bad ones in
their place, in order to benefit later from having the
good decisions at hand.  Good design decisions have
value only when they are deployed.  They are good only
in a context where they balance forces in a pleasing
or supportive way.  "Spending" bad design decisions
in code doesn't get rid of them; it requires that we
live with them every time we touch the code!

So, equating the phenomenon that Kent described with
Gresham's Law would be to misuse the law.  If I did
so, I wouldn't be alone.  Robert Mundell discusses
faulty renderings of the principle in an
<A HREF="http://www.columbia.edu/~ram15/grash.html">
   academic paper</A>.
It wouldn't even be the first time I made the mistake.
I remember vividly the night I took a midterm exam in
my undergrad macroeconomics class.  I misstated
Gresham's Law in one of my responses.  My instructor
was wondering around the room.  He saw my answer,
leaned over, and whispered into my ear that I should
think about that question again.  I did and was able
to correct my answer.  (That guy was a way cool teacher,
and not just for helping me out on the exam.)

When I saw Kent's tweet, I did not make that mistake
again.  I answered his question with "<EM>a perverse
malformation of Gresham's Law?</EM>"  John Mitchell
offered
<A HREF="https://twitter.com/#!/johndmitchell/status/2061950070558720">
   his own colorful phrase</A>:
<EM>viral toxicity</EM>.  That is almost certainly a
better reflection of the phenomenon than mine, yet
the ring of "the bad drives out the good" still
appeals to me.

I think Kent's question is worth thinking about some
more.  Bad design does seem to infect other parts of
the system and spread, by requiring us to deform other
code to make it work well with the bad code, to fit
with the bad structures we've already created.
Perhaps Viral Toxicity is a sort of Gresham's Law for
software, a phenomenon that developers need to be
aware of and guard against.  Maybe if we talk about
the viral toxicity of bad design, other people will
understand better the value and even necessity of
regular refactoring!
-----