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!

• Noel Llopis peers at us from Games from Within and states something that I thought was a given in performance-sensitive environments – pure or near-pure OO can be a speed drag. This post really is a solid explanation of the philosophical differences between object-orientation and data-orientation, and those differences parallel why you’d choose a normalized versus de-normalized database schema.

  I recall being advised to design my objects to optimize caching, and if we were designing a game, I’d agree. But we’re not. We are a textbook example in favor of not doing this and going the domain-driven route, which I fully intend on pioneering.

• Jeanne Boyarsky of Down Home County Coding gives a female coder-clinger’s view on female programmers and programmers-to-be.

  First of all, I don’t care what your gender is, I care if you can write clean code. Second of all, based on my experience during my thus-far infantile career, I am noticing that most of the women on our development teams are in non-coding roles: managers, point-haired bosses, UI design, testers, requirements people, etc. Third of all, regarding role models, I share the opinion of Tony Dungy that you are a role model to someone somewhere, whether you know it right now or not, so you’d better carry yourself like someone is watching you.

• Helltime-favorite Giorgio Sironi cites the tale of the angry monkeys. In short, if you don’t make every entity class a bean, don’t use primitives, and don’t do more than simple initialization in your constructors, you will be beaten by a gang of angry monkeys.

  Of the three practices, I find the first and third the most abhorrent. And by the way, I wouldn’t call them monkeys. It’s disrespectful to monkeys.

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!

• Steven Lott makes a declaration on DZone JavaLobby that would make Dilbert himself proud: the problem with software development is project management. Amen!

  The article is mainly a laudation of Agile, but the praise is well-justified. The attack is mainly on traditional project management, and comes on the heels of a devastating indictment by Dimitris Staikos. I might even take this one step further: what does the Scrum master even do all day? Based on the article, all of the labor of traditional project management is a waste, so a Scrum master doesn’t have that much to do during the day. Can anyone say “overpaid”?

• From the PureDanger blog of Alex Miller: The Next Big Language is… null. Alex asserts that the era of multi-language projects is here. If this is true, then continual learning is going to be of even larger importance than it used to be. Having adequately explored the basics of Smalltalk, I have personally started to look at Erlang, mainly because it is a different paradigm than the one I use every day.
• Right on cue: Julian Exenberger responds to Alex on Dot Neverland, making the point that 1) most programmers work for companies where IT supports the main business and 2) as a consequence of #1, these companies trend towards stability, and there is stability in choosing a language and sticking with it.

  This is a highly valid point. When I asked my architect what was coming after Java, I didn’t get an answer because I don’t think anybody in our organization has any plans to move away from Java. Do you blame them? Why shift paradigms or even languages when most of your coders still believe in procedural Java?

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!

• The first of two DZone articles, Mark Needham says to only mock the types that you own. The example cited is when unit-testing something that uses Hibernate. I haven’t used Hibernate, but I think the advice itself needs to be qualified further. I say to mock whatever you need to mock to get the job done. I agree that most times, when you write a class that uses a framework, the framework is part of the object’s core functionality and should be tested. But if this ends up not being the case, I never fear mocking what I need to mock. I have, on more than one occasion, extended java.io.File and java.io.Reader.
• Cody Burleson has posted a good starting point for how to do logging in Java. One thing I’d like to know is why design the logger this way:

       if(LOG.isTraceEnabled()){
            LOG.trace(">> myMethod()");
       }
  

  when you could push the conditional into the trace() method:

      LOG.trace(">> myMethod()");
  

  I posed the same question to our architects and never got an answer. Another comment is that I believe in logging when unexpected exceptions occur and including stack traces as the preferred approach to littering code with trace statements. My hope is to write code that can be sufficiently debugged through a stack trace and a dump of useful variable values when something goes wrong. It’s kind of like writing comments: try to write code that doesn’t need comments.

• Another DZone feature by Mike Cottmeyer is a reminder of what agile is actually about: getting things done. One thing I remember from my software engineering courses is that productivity = business value / lines of code. The fastest way to maximize this function is to reduce the lines of code to zero. So if you can buy it, don’t build it.

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