Natural Selection in Software Production

I had an interesting conversation today about coding standards, it started with a document How to write unmaintainable code. One of my collegues sent this out after reading slash-dot. It reminded me of, perhaps a more cynical version, of How to get your abstract rejected.

How much of this is tongue in cheek and how much understanding of the natural processes involved is there. Quoting statements like:

Let's face it, you and I and everyone else are going to write crap code anyway, so it may as well be cheap and simple crap code that you understand and can afford to throw away rather than complicated and expensive crap code. (The fact that 90% of the code written by 90% of developers is crap is a corollary of Sturgeon's law that 90% of everything is crap.)

Could be seen as cynicism. I thought actually much of what goes on here can be described in linguistic terms:

Doesn't that just prove that programmers are a cynical bunch that don't get out enough? There are flaws in nature, only the solution that best-fits survives. If it doesn't fit at all, or isn't adaptable it faces extinction. The cross-cultural pragmatics of software communities are largely irrelevant given the real selector of success is the market. Its role is in the developers actually agreeing in how they understand and interpret code. Some of this material reinforces the individualistic idea of software development.

It's funny though even if it is a caricature.

There may be an interesting article here somewhere. Ultimately the selector for software is the marketplace, --- the characteristics that cause the system to be selected (or not) are what is built. Engineering is about selecting the correct characteristics for longevity in the market.

I equate these difficulties to the "tragedy of the commons". I have slide, from game theory presentation, that goes something like:

Avoiding Tragedy of the Commons (TOC)

1. Private Ownership
   • Prevents TOC, but may have other negative effects
2. Social Rules/norms, external control
   • Nice if they can be enforced.
3. Taxation
   • Try to internalise costs; a system of accounting is needed.
4. Change the rules of the game
   • Change individual pay-offs
   • Mechanism Design

This maps onto software development:

1. Component ownership (non-collective ownership). Could be bad as real cost of software that is meant to last is in maintenance. Perhaps this is based on what your maintenance costs are, and how senior the owner is.
2. Convention, team working, the establishment of a culture. So coding standards etc... Mutual respect.
3. Penalties for doing the wrong thing. Accountability. Stay till it's done.
4. Tools, Techniques, Story boards, etc....

In real society you might notice for [2] that idioms and practices are ostracised (like your original mail) but you are better off naming each (like an anti-pattern) so you get the equivalent of the "Chav" as a coding idiom. Possibly difficult to establish

(perhaps also Wisdom of Crowds-- Q and A)

Many people bring legacy systems back to life through refactoring, I spoke to someone only last week. They'd got a system back from India and needed to re-engineer portions (there were no unit tests, acceptance tests etc...). Isn't this more common than not?