[DrunkAndRetired.com Podcast] Episode 11 – Large Teams, Shitting the Field, Perfectionist Coders

A team of 100+ developers will generally develop a system so complicated it could only have been developed by a team of 100+ developers. —Darren Hobbs

In this episode, we talk with Darren Hobbs about working with a large (100+) pool of programmers on a project. And, of course, there’s some poop-jokes: gotta have that.

Thanks go out again to Zane for letting us host the MP3s on the Liquid Labs servers.

(This episode edited by Coté.)

When Autoboxing Attacks!

We started using J2SE 5.0 (or “1.5” as everyone calls it) a little while ago. Here’s a fun little autoboxing typo-bug I just did:

// in some class that implements java.io.Externalizable

  private long startDate_;
  private int intervalMinutes_;

  public void writeExternal( ObjectOutput out )
    throws IOException
    out.writeLong( serialVersionUID );
    out.writeObject( startDate_ );
    out.writeInt( intervalMinutes_ );

  public void readExternal( ObjectInput in )
    throws IOException

    startDate_ = in.readLong();
    intervalMinutes_ = in.readInt();

// When run, throws:
Caused by: java.io.EOFException
 at java.io.DataInputStream.readFully(DataInputStream.java:178)
 at java.io.DataInputStream.readLong(DataInputStream.java:380)
 at java.io.ObjectInputStream$BlockDataInputStream.readLong(ObjectInputStream.java:2748)

Yowz! WTF, dude? The problem is with that out.writeObject( startDate_ );. It’s autoboxing the long into a java.lang.Long, and then shitting the bed when it’s reading it back in as a long.

Luckily, it’s an easy enough to fix to do out.writeObject( startDate_ ); -> out.writeLong( startDate_ );.


I’ve been noticing a lot of people talking about working long hours recently, mostly on the topic of “I want to work less” or, at least, “differently.” That uptick in occurrences could just be because I’ve been thinking about those things more and more recently. Regardless, here’s some interesting fragments.

Avoid Bosses Who Work Long Hours

Adam Barr (author of the interesting MSFT book, Proudly Serving My Corporate Masters) all but posists a sort of “Rule of Work” in a recent post:

Microsoft does not have its employees on a fixed work schedule, so you wind up with some months where you work harder and some months where you can goof off a bit. BUT, overall, this attitude is a reflection of the overall Microsoft attitude towards time management:

  • Take all the employees who react to having too much work by working extra hours, instead of cutting work–in other words, the employees who don’t have good time management skills
  • Promote these people into management positions where they are responsible for scheduling software deliverables
  • Scratch head when your software isn’t done on schedule

Put another way:

  • There is too much work to (in 40 hours) do for the goals that are set.
  • Some people don’t do anything differently.
  • Other people will start working as many hours as it takes.
  • This second group of people is rewarded with, among other things, promotions, and become management.

It’s a sort of mix of two classic org-theories, The Peter Principal and Parkinson’s Law: people are promoted to their level of incompetence, and work expands so as to fill the time available for its completion.

Furthermore, these “long hour bosses,” like all humans, will expect that the only way to be a good, successful person (resulting in bonuses and good treatment) is to be more like themselves. Meaning they’ll think highly of people who work longer hours, just like they do. When they encounter a problem, more than likely, they’ll golden hammer it and immediately think, “well, we just need to work longer hours. What else can we do?”

Thus, if you find yourself working for a boss who works long hours, there’s a good chance that you’ll be expected to work long hours. Furthermore, chances are the fact that you have to work long hours will never be seen as a problem, and, thus, you’re doomed to always have to work long hours.

As I’m fond of saying, I learned more about pragmatic human-psychology in dog obedience school than I did in school: dogs do what they’re rewarded for and conditioned to do, and if you start randomly rewarding them, they do it even more consistently. People, if they don’t watch it, are the same way.

Applying this thinking: your boss will never initiate and (rarely) accept any idea to reduce the number of hours worked. More subtly, anything that causes you to work less hours will be seen with suspicion: if you’re not working long hours, something’s going wrong, ’cause long hours are the path to success and more dog treats. They’ve been heavily rewarded, with promotions, for working long hours. So, long hours are a pleasing, good thing to them (more treats!). Layer on the goose/gander equation, and you can understand why that boss wants everyone to work long hours.

So, if you don’t want to work long hours, you’ll want to avoid working for a boss who works long hours. It’s not 1-1 (your boss might work 40- hours and expect you to work 50 hours), but I’d say it’s damn close.

(Link to Adam’s post via Steve’s bookmarks.)

Money and the Future

60 Minutes II had a story this week about the French work ethic. Essentially, aside from a gratuitous dissenter, the opinion expressed was “work as little as possible, and take lots of time off.”

I always get a little greener-on-the-other-side syndrome, and chuckle sadly, when my fellow country-folk make fun of the French: “Yeah, work only 35 hours a week; pretty much free health-care and school; have America pay for all the policing/wars in the world and like it; fresh, cheap baguettes; living in France. It sounds absolutely terrible! Who’d want all that?! It sounds like a life of sin-a! Where’s Calvin when you need him?!”

The two comments from the French interviewed that I’ve been tossing around in my head-can were (paraphrased):

  • It’s easy to work 35 hours and take lots of vacation when making more money isn’t your number one goal. (Editor of major daily.)
  • It’s easy to work hard if you think the future will be better than the present. We don’t think the future will be better than now. (Corinne Maier)

So, consequently, the report goes on, people have at least a month of vacation every year and they’re mandated by law to work only 35 hours a week (with over-time comp’ed by more vacation). Sounds terrible!

Michael Sr.’s Rule of Work

My dad has a pretty pragmatic philosophy about all this. He’s a damn dedicated worker and he always brings home the bacon. He seems to apply what we might calls Michael Sr.’s Rule of Work: “You can be replaced or off-shored. There’s bills to pay. Suck it up.”

Fixed Podcast Feed

If you subscribe to the normal DrunkAndRetired.com feed, you can ignore this post, as it’s about the podcast only feed.

The DrunkAndRetired.com podcast only feed is now fixed. The servers had a little configuration error, which was fixed, but the URLs depended on the error. BUT, now it’s all gravy!

Thanks goes out again to Zane for letting us host them MP3s at Liquid Labs.

So, if you’d like to subscribe to a feed that has all the DrunkAndRetired.com podcast episodes, and only the episodes, subscribe to http://feeds.feedburner.com/DrunkAndRetiredcomPodcast.

The feed doesn’t have any weblog content, so you’ll still want to subscribe to the normal feed in bloglines and other aggregators. And, the normal feed will still have podcasts in it.

Is that confusing enough?

iTunes 4.9 Out: "The Last Nail in the Coffin"

In case you haven’t noticed, iTunes 4.9, with podcasting/catching features is out. I haven’t loaded it up and played with it yet, but Matt Ray says it’s the “last nail in the coffin” for other podcatchers.

Earlier this morning, you had to download it from the site, but it’s now available by running Software Update. There’s also an iPod update.

Anyhow, we’ll see how it goes.

Update: here are some screen-shots. And check out these two posts from Josh Hallett:1, 2.

James Fairbairn notes that you can subscribe directly to podcasts without them being the iTunes podcast store. Under the Advanced menu, you just click the “Subscribe to podcast” option, and then paste in the URL for the podcast’s RSS. That’s easy enough.

Tags: ,

Some Bullshit on Agentless Monitoring

Agentless typically provides lightweight monitoring, with limited depth of data gathering or monitoring capabilities. In addition, without code or management intelligence installed on the system, the opportunities for management are little to none. The advantage is the ease of deployment – there is no need to deploy the agents – as well as the ease of maintenance. Despite its limitations, if the agentless monitoring provides all that you need for a specific device, then it is probably the right choice for you.

In addition, the agent-based approaches can deliver management capabilities through the interaction of the agents and the management servers. In short, the agent-based products offer more robust management (including monitoring) capabilities than the agentless varieties.

Yeah, that’s a bunch of bullshit. Agentless monitoring will get you exactly what you want, in any depth or amount of robustness about 95% of the time. I can guarantee that statement ’cause, having worked on an agentless system for some years, I’m one of the people who write the code.

The fact that there’s an image that agent-full monitoring is “beefier” is due to only two things: (1.) legacy and (2.) agentless people’s strong desire to keep things as simple as possible.

I say “legacy” because agent-based monitoring has a conceptual first-mover advantage. So many monitoring systems that have been around for a decade or more were originally coded to be agent based, putting it people’s minds that if you’re going to monitor something, hard-core and all, you need an agent. People just don’t think otherwise. But, now-a-days, you can get pretty much anything you want remotely without the need to install anything on the target machine — except maybe a username and password so you can access the box (which the agent system would need to get installed).

And, by simplicity I mean that (at least those I know) agentless people tend to prefer having 5-10 really good monitoring metrics over 10-50 everything-you’d-ever-want metrics that agent systems tend to have. Put another way, just because you’re monitoring more metrics doesn’t mean you’re monitoring more quality metrics.

So, if someone comes up to you and tries to tell you that agentless monitoring isn’t going to cut the mustard, be sure they know what they’re talking about. Sometimes it’ll be true, but in more cases than not, they’ll be wrong.

(Of course, none of this should matter to you if the systems management system does exactly what you want, and TCO’s equal to, or less than, what you want to pay. Agent vs. agentless is a distraction if your needs are taken care at a good overall price.)

[DrunkAndRetired.com Podcast] Episode 09 – What Sucks About Ruby on Rails

In this episode we talk more about the problems with Ruby on Rails, along with some discusion of extending Xerces to get some basic JavaScript stuff tested.

Feel free to send feedback to the comments below, or email either audio recordings or comments.

Thanks to Zane Rockenbaugh of Liquid Labs for hosting the MP3s for us with his mega-pipe to the ‘net.

(This episode was edited by Charles.)