Why Software Jewels Are Rare (1996) [pdf]
One of the things that I have noticed in my career is that the industry, in my opinion, does not seem to value craftsmanship in software outside of a few niches.  After all, for most people, software is simply the means to an end, and this includes the software industry.  Those who make software for a living have to deal with market pressures, deadlines, and other factors that sometimes conflict with meticulous design.  &quot;Move fast and break things,&quot; &quot;perfect is the enemy of the good,&quot; and &quot;worse is better&quot; are the mantras of our industry, and that&#x27;s because today&#x27;s economic incentives favor functional, if imperfect, software over meticulously-designed software.  I won&#x27;t name examples since I don&#x27;t want to start a flamewar, but there is plenty of software that is &quot;good enough&quot; but isn&#x27;t designed very well, yet happens to be widely adopted.  Likewise, the jewels of software don&#x27;t seem to be well-adopted and seem to be restricted to research niches, with some exceptions.  I lament this, and I wish I could work in a niche that favors software craftsmanship, but this is the world we live in.<p>Perhaps the solution to making software jewels less rare is to make it easier for software engineers to make jewels by creating more sophisticated developer tools, so that way the quick-and-dirty approach just so happens to align with &quot;the right thing.&quot;