July 2008 Archives

A recent revelation for me has been that I don’t spend eight hours a day programming. This was a shock. For a long time I was estimating my effort as if I was spending every minute of the work day slinging code. If I estimated a project at forty man-hours, I would figure eight hours a person per day and do the math from there.

The simple truth is that you don’t work on a task for eight hours a day. I’d hazard to say that at best, you can do four.

It is impossible to convince people of this fact.

We like to think of ourselves as hard workers. We take pride in our dedication. How dare anyone suggest we’re giving less than one-hundred percent? Ego gets in the way, even in the best-intentioned of people.

I know you don’t believe me. Thankfully, you don’t have to. Grab yourself a trial version of TimeSnapper, fire it up on a Monday, and forget about it for a week. On Friday, play back your days and see just how much time you spend productively coding. I’ll guess it’s not as much as you thought.

It’s ok to cry. I went into denial when I first saw my results. I tried to convince myself that the recording was wrong, and that I was spending more time writing code than the machine itself had recorded. In the end, the truth set me free. A lot of time goes to meetings, discussions, fire drills, random tasks, email, and the internet. Not to mention task switching.

My absolute maximum task dedication is three or four hours of coding on a single project  a day; and that’s a day without scheduled meetings and few formal interruptions. While a little depressing, this is useful information. When it comes time to estimate development for a new project, I know not to budget eight hours a day.

In the end, knowing where your time goes makes it easier to spend it wisely.

Writing Untestable Code

| Comments

The Google Testing Blog has a great post about how to write code that is impossible to test. The list is a handy scorecard to compare your work to. I was happy to see my sentiments about evil constructors echoed in one of the items:


Heavy Duty Constructors - Make constructors that do lots of work in them. The more work you do in the constructor, the hard it is to create your object in a test fixture. And if your constructor can construct other things that are hard themselves to construct, that’s even better! You want the transitive dependencies of every constructor to be enormous. Enormous is hard to get under test.

Maybe Gradual Change Is Dumb

| Comments

I caught an episode of Gordon Ramsey’s Kitchen Nightmares tonight on the wisdom-box. Being the 37Signals Fanboy that I am, I was on the lookout for what Gordon could teach me about building software.

Right away I noticed the staff’s resistance to Gordon’s redesigned menu. He threw out the old seafood roster and changed everything over to hardcore steakhouse in a couple of days.

I realized that I tend to have a similar view of drastic changes in software:

  • Isn’t that risky, doing all of that at once? Why don’t we just do a small part first to see how it goes, hmm?
  • We really don’t need another big bang project. They’re hard to do, and they’re always late.
  • Let’s just evolve existing features, instead of always blowing them away and starting from scratch
These are reasonable, pragmatic positions to take in a world filled with scope creep and feature bloat. The only problem is that this kind of thinking paves the road to stagnation. They’re the attitudes of a crappy restaurant staff facing drastic but badly needed changes.

Gordon ALWAYS nukes the menu and starts over. If things are bad, or if you really want powerful change, incremental improvements won’t cut it. At some point, you’re going to need a big bang. It will probably hurt.


One thing I’ve learned when using dependency injection is that initializing one or more class instances in the constructor of another is a sure sign you haven’t separated your interests well.

Miko Hevery has summarized this far better than I’ve ever been able to in his post about how to think about the “new” operator.

In this case, what’s true for Javer is equally true for Python. Many is the time I’ve gotten up the will to write tests for some legacy code, cracked open the module, seen the five or more objects created in init, closed the file up, and quickly walked away.

Invoking constructors for other objects in your constructor is not only bad for testing; it’s bad for maintainability. By putting them in there, you proclaim to the universe “THIS is the type I want to use here, forever and ever, until the sun burns out and the sky falls down. Amen”.

I don’t know too many people willing to commit to something to that degree. Maybe the Pope would.

I collect mocking frameworks like some people collect figurines. So I’m very interested to see if Google’s Mox is any good.

At first glance, it seems to be very mocker-ish, but I’m sure I’ll find some noteworthy differences. If you beat me to the punch, please post a comment and lemme know what you think of Mox.

[via AgileTesting].

Have the Guts To Cut

| Comments

nurseofdoom.png

43Folders highlights a list of seven points from Kurt Vonnegut about how to improve writing. My Favorite is point #4:

  • Have the guts to cut
As is often the case, what’s good for writing is also good for writing software.

Of all the features that were dreamed for your last project, how many were delivered on time? I’m guessing not many.

At the end of the day, a few features will probably drive the bulk of the benefit.

Why don’t we save ourselves the trouble? Cut extra features early and not wait for the schedule to do it for us. Go on, be a ruthless killer.

Nurse of Doom photo courtesy rochelle, et. al. some rights reserved.

Delaying the Eff-it Moment

| Comments

One of the key benefits of testing and TDD is delaying the Eff-it moment.

The Eff-it moment happens when you’re diligently slinging code: writing tests and building modules to satisfy them. One day you do some quick math and realize you’re not going to hit the deadline at your current pace. You quietly declare, “Eff-it, I’m just gonna get it to work”.

You stop testing and start slamming crap in to make your deadline.

This has happened to me. I’ll argue that it happens to just about everyone who attempts any degree of test-driven development.

I think it’s important to see TDD as a way to stave off the Eff-it moment, not it’s executioner.

If you ARE human, and you don’t make it all the way through before you hit Eff-It, don’t be sad. You’re still OK. The tests you manage to write help you and will help others.

This kind of discipline takes nerves of steel. It’s like base jumping (righteous video, btw). You need to trust your tests and stay calm in the face of a rapidly approaching deadline/canyon floor.

Just as trust in equipment is built over time, so is trust in testing. It won’t happen the first time out of the gate. You’ll chicken out eventually, but just keep testing as long as you can.

Each time you’ll learn more, and gain more confidence and trust. Eventually you’ll be doing whole projects with the calm nerves of a seasoned extreme athlete.

So you’ve likely seen Webslug, the neato tool that lets you battle sites against each other for fastest load time. I suggest you try it out, but only to start you thinking about performance.

When I saw my site lose to traceback.org (grrrrr), I started contemplating what I have on CodeSoftly that’s bogging things down. I came up with three right away:

These in turn got me thinking that I really ought to profile my site performance to see what’s else might be bogging things down.

This got me thinking that maybe I can optimize the markup behind the site to shrink things even further.

THAT got me thinking about what the fastest site ever would look like.

A single loss got all that going. Coolio.

IndianGeek.net has a ginormous competency matrix for programmers. It lists out four “levels”, like “2^n” and “log(n)” (yes, that’s math in the column headings), along with umpteen facets of programmer skills.

All I could think of when browsing this behemoth chart is the beginning of Dead Poets Society. The class reads a poetry introduction explaining that a poem’s greatness is measured by finding the area within a chart plotted on perfection and importance.




I’m positive there’s a log(n) programmer out there that nobody wants to work with. I’m also sure there’s a dude or girl who knows a single language (kinda) but makes money for their business because of their passion and dedication.

We’re people. Judging someone with even moderate input from a chart is chancy at best.

I humbly submit a few extra categories for consideration:

  1. Passion
  2. Getting Along With Others
  3. Telling Good Jokes
PS - if you ever see me moping around complaining about only being an n^2, please hit me over the head with a steel folding chair.

Make Email Count

| Comments

Email is an imposition. When you send it, you’re broadcasting “pay attention to me!” to whoever gets it. It’s important that you keep your email rep high, so that your communication doesn’t get lost in the shuffle. Here’s a few tips I follow when composing electronic gems:

  1. Write a meaningful subject. A subject line like “The site redesign is behind schedule” is much better than “redesign”.
  2. Get to the point. Summarize the entire message in the first sentence or two. You can provide background info and details in later paragraphs.
  3. Keep it short. People don’t read long email. If you’re writing a document, do it in a word processor and attach the file.
  4. Put a single address in the “to” field. Addressing mail to more than one person ensures nobody will do anything. If you really need it to go to two people, consider sending two different messages.
  5. Be polite. Antiquated though it may be, use greetings and closings in your messages. Politeness is an extension of respect, and people respond to it.