The Leprechauns of Software Engineering

This issue ended up with a strong Leprechauns of Software Engineering vibe. The précis from the book landing page:

The software profession has a problem, widely recognized but which nobody seems willing to do anything about. You can think of this problem as a variant of the well known "telephone game", where some trivial rumor is repeated from one person to the next until it has become distorted beyond recognition and blown up out of all proportion.

Unfortunately, the objects of this telephone game are generally considered cornerstone truths of the discipline, to the point that their acceptance now seems to hinder further progress.

The corpus of such “cornerstone truths” grows at breakneck speed. This issue covers “Test-Driven Development leads to better code” (it may, but there’s no evidence for that), “static type systems improve safety” (they may do, but only incrementally), “a proper database is faster than SQLite” (it can be, but check for your application), and “Perl sucks” (that’s just, like, your opinion).

And those were the ones I had collected 25% of the way into curating the article! I don’t think there’s necessarily a “solution” to this: groups form shared values, people signal those values to indicate membership of the group. Last decade’s programmer conference groupspeak was Clean Code and TDD, the current groupspeak is about static types and “reasoning about” code, and in a decade that will be out of fashion and another set of topics will be de rigeur.



Around the web