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!

• On The Server Side, Eugene Ciurana lists 5 myths about old-time developers. Since I work with a couple of old-timers, let’s go down the list.
  • Older software developers are more expensive than younger ones, making younger developers more desirable. Well, maybe. I’ll flip this one on its head: younger software developers are easier to exploit than older ones.

  • Older software developers are less flexible and less capable of learning new technologies because of their legacy knowledge. This one is rubbish. This totally depends on the person and their level of OCD.
  • Older software developers are less able to perform the arduous tasks of software development (read: work long, painful hours) because of family commitments and other attachments that younger workers don’t have. Again: younger software developers are easier to exploit than older ones.
  • Older software developers are less mentally agile than younger ones. This one is just silly. It’s probably just the opposite.
  • Older software developers are more jaded and cynical and therefore, less desirable in the workplace than younger ones. Younger developers are more enthusiastic than older ones. Sorry, but I think jaded cynicism is a key character strength for anyone trying to swim through the shark-infested water that is software complexity.
• Jay Fields guest-blobs on the Java DZone about brittle unit tests and ends up concluding that all you need to do is to test less. Yeah, that’s just the easy way out.

  I don’t deny that there is a problem. I have written about brittle tests before. Certainly if you don’t follow the “mockist” approach, you run the risk, but even if you do, if you, say, add an argument to a method of a class, you have to check all of the mocks of that class and make sure you add the same argument to all of them. Otherwise, you won’t be overriding the method you need to override anymore in the case of a mock that extends. You face a similar problem if your mocks implement interfaces.

  Even so, this is no reason to only test “the important parts” of the application. My experience hasn’t been as dramatic. I haven’t spent 80% of my time adding an argument to a public method just going around and fixing my unit tests. It is usually less than 50%.

• Helltime-repeatant Giorgio Sironi hosts 3 steps to grow a Ubiquitous Language on his blog. I start by not necessarily agreeing with step #1’s decrying of synonyms. I certainly understand the point, but on our project, we do have a few names for a single concept, but we have a primary name that is understood to be the one we use the most. I find step #3’s advice to maintain the Ubiquitous Language to be the most curious: how do you maintain something that is fundamentally intractable? I think better advice would be to maintain the code to match the Ubiquitous Language.

  Even this blog has its own little Ubiquitous Language: MoffDub, Code Agitator, Menace, Right-Wing Extremist. 6 and one half, really.

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