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. |


