A few links on the topic of software engineering

• First off, an interview with Professor Sidney Dijkstra discussing the importance of assigning the right people to the right job on a software development exercise. On GUI development for example,
  

  I’d estimate that of every 100 programmers asked to turn their talents to GUI design, 20 “get it” right away, 40 can be made to “get it” with suitable prodding and 40 never “get it” even if the prods pack several kilovolts.

• Next, an entertaining comparison of the evolution of a software development to that of an apprentice bear hunter. Anyone who’s ever had to find work suitable to give an apprentice developer, and then despite the developer’s best efforts, had to rewrite the whole thing from scratch will relate to this only too well.
  

  Stage 3: Apprentice. A Stage 3 has attended a 5-day seminar on bear hunting. During this seminar, the participants form into teams of three or four and practice hunting very small bears under the ever-watchful eye of the instructor. After a few interim setbacks, by Friday afternoon all the teams have successfully hunted their bears. They fill out evaluation forms attesting that “bear hunting is very useful and relevant to my job.” However, they are barely prepared for the world of real bears.

  …compare to…

  If a Stage 3 absorbs everything from a seminar, then he is minimally equipped to tackle a true, full-sized project in the corporate jungle. Usually, however, a Stage 3 does not grasp everything or has difficulty scaling the techniques up from a case study to a real project. You could say that most Stage 3s know just enough to be dangerous!

  My favourite quote though has to be “It’s typical that some Stage 4s get some bears; but it’s also typical that some bears get some Stage 4s.”. Amen to that, I’ve seen plenty of apprentice software engineers ‘got’ by bears. Still, applying Darwin, this can only be a good thing, since those which get the bears are that much sharper.

• Finally a look at the folly of applying buzzwords such as “2-phase commit” in situations where a far simpler architecture would be more that sufficient. The most important take away from this short article is the way, if one accepts the possiblities of errors, their resolution can actually be less trouble, than preventing the errors in the first place. ie, if using a DB server along with MQ messaging, one instinctively jumps for ‘XA’ (distributed transactions), however, if one has reliable detection of duplicate messages, XA is completely redundant. It may be feasible to merely commit the database first, then the worst that can happen is the MQ rolls back, in which case a message will get processed a 2nd time – but the duplicate detected & discarded.