I Built His Cage

Announcer: Now for quick hits and commentary on software development topics from around the web, the EIP web-ring brings you the stigmatized spawn of a refactory, MoffDub, and Helltime!

• I won’t feign that I have read the entire article, but the Best In Class blog has an interesting comparison of Python and Clojure, and this is timely given the recent milestoning I did of current software engineering trends (as I see them, anyway).
• Lori MacVattie of DevCentral gives us the real reasons why legacy applications don’t die. Hint: it’s not because nobody understands them. Quite the opposite; Lori correctly identifies that one of the driving reasons behind their longevity is “if it ain’t broke, don’t fix it”. There is, however, a more primal one.

  Having been reassigned and elevated as the business-layer tech lead of a new project, I can confirm this. Our project manager noblely wants to re-implement the functionality of a legacy project in order to avoid impacting all those who depend on it when we make our changes. I politely reminded him that someone would need to pay for that, and I doubt our project sponsor would be on board.

• Helltime repeatant Davy Brion extols us to stop exposing collections in our objects. Yes! Correct. In Java, I have grown fond of Collections.unmodifiableList(), but be aware that this makes the list read-only, not the individual elements.

  Fortunately, my design allows for this, but if you need something stronger, consider a custom read-only implementation of the content-type of the collection. Otherwise, you still run the risk of modifying the contents of a collection outside of the containing object, and this is especially bad if a) you don’t want that to happen, and b) the containing object is an Aggregate root. Ouch.

Announcer: You’re reading the EIP web-ring.

Announcer: Now for quick hits and commentary on software development topics from around the web, the EIP web-ring brings you the stigmatized spawn of a refactory, MoffDub, and Helltime!

• Blogoscoped reminds us that good programmers are both dumb and lazy. Philipp Lenssen reports:
  

  Lazy, because only lazy programmers will want to write the kind of tools that might replace them in the end.

  Yeah.

  Second (and I will elaborate a bit more on this because I find the concept to be less known than the first) a good programmer must be dumb. Why? Because if he’s smart, and he knows he is smart, he will:

  a) stop learning
  b) stop being critical towards his own work

  Mmm hmm. Yes. I think this is correct but dumb is not the right word. The right word is paranoid; paranoid that one’s day job is silently sinking one’s own career by its lack of evolution.

• A fun post by Peter Kellner sings the praises of the semi-colon and indentation-neutral languages in general. I tend to agree. Dittohead programmers (yes we exist) all rally behind the premise of freedom, and freedom from indentation and spacing czars is no different.
• Now for the flame-bait of the day: Daniel Alexiu rips dependency injection, claiming it makes your code worse, not better. Hehe.

  I used to share Daniel’s phobia of XML files meaning more than the code itself, but I got over it once I hand-rolled my own dependency injection framework to better understand what that angle-bracketed black magic was doing for me. I’ve been known to hand-roll from time to time just to learn stuff.

  Come to find out, the entire rant is a facade for a larger complaint about OO in general. And aside from his valid complaint about mutable state and how hardly anyone uses Java in a truly OO way, I don’t see his gripe. Code is too abstract? Sounds like an assembly coder to me.

Announcer: You’re reading the EIP web-ring.

Announcer: Now for quick hits and commentary on software development topics from around the web, the EIP web-ring brings you the stigmatized spawn of a refactory, MoffDub, and Helltime!

• Inquisitive Coder Davy Brion says that the only thing you can learn from code coverage is what you haven’t executed, and he is right on the money. This doesn’t stop me from striving for above-90% code coverage, but I don’t claim my code is bug-free at that point. The only thing coverage tells you is what you didn’t bother to think about.

  Not even that. You can obtain 100% coverage and your tests can still suck. Low coverage only tells you what has been completely neglected.

• From something called The LingPipe Blog comes the futility of writing comments. It’s an old, oft-repeated-but-hardly-followed rule: comments are a code smell. But like all code smells, it isn’t always a problem. I write comments mainly to explain something later to myself that I know I won’t remember, either algorithms or (poor, forced) design decisions.
• Alberto G’s Making Good Software blog slams the “magic architecture“. Finally.

  Not only should software architects read this post, but most of you professors in academia should as well. Every time you people try to kill your students with a kamikaze death-by-PowerPoint-boxes-and-arrows lecture, remember that I am paying you to explain things to me, not to remember what it was like to sit in your private office right before your PM fired you for being unable to write a line of code because you were too busy drawing boxes in MSPaint.

Announcer: You’re reading the EIP web-ring.