Helltime for February 26

Posted in Helltime with tags on February 26, 2010 by moffdub

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.

Guess who’s guessing?

Posted in The Industry with tags , , on February 24, 2010 by moffdub

Well well well, here we go again, yet another fit of February Fury from Mother Nature, but that won’t stop me from being away from my code or being away from my blog. MoffDub here on the one and only Excellence In Programming web-ring, here to present you with a tale of estimation happiness.

Eventually, getting wrongfully chewed out by incompetent PHBs gets old, so, one day during sprint planning, my cohort got out his pen and calculator and started guessing approximately how many days the work we had for each story would take. By “day”, I mean a relatively uninterrupted six-hour period, and multiply that by two for the two of us working together.

Why six? Because out of your eight hour day, you are liable to lose two hours to unplanned interruptions, and that context-switching cuts into the productivity you experience while in your “programmer flow“.

Read more »

When inheritance hierarchies lose their structural integrity

Posted in Design Issues with tags , , , , on February 17, 2010 by moffdub

Let the record show that the number of work days I missed due to inclement winter conditions is zip, zero, nada. So tell Mother Nature to take her power outages and her blizzards and suck. On. That.

Did you really think some crystalized water molecules were going to keep me from my code? Girl, you MUST be crazy.

In fact, a new episode of Nowhere To Run was forthcoming on Saturday, but I succumbed to fatigue and the call of my nice couch/bed at a paltry 9 P.M. I am so old.

Allow me to posit something to you, folks. Suppose this is your nice, beautiful code:

Read more »