April 2010 Archives

Working harder doesn’t help.

I’m not talking about it in the “work harder, not smarter” kind of way. I mean the way people use effort as a panacea for their project process woes. It makes zero sense to say “we’ll work harder” to explain why things will be better this time.

Ask a 110 pound kid to bench press 200 pounds. Of course he can’t do it. Would you have him come back in three months to try again, with the only difference being that he’s going to try a lot harder? Heck no. He needs to prepare by beefing up, or alter the challenge to become something he can complete.

Lots of times we do this with software projects. If you’re a serial death-marcher or are constantly over time and budget, the instinct is to try again under the false assumption that putting more effort into it this time will magically create better results.

If your projects hurt too much or don’t come in on time, you probably need to make some material changes. If you really love waterfall, but it’s not working, figure out what you can change to fix your problems. You may want to try something completely different. Whatever you do, don’t spread the rumor that mere effort will make things OK.

Ticketing for Fun and Profit

| Comments


If you’re in a typical software shop, you have a ticketing system to keep track of things. Most often these tickets track defects. Bugs.

The proper use of the ticketing system is part art, part science, and part turtle herding. Get it right and your process is a well-oiled machine. Do ticketing badly and your days will be nasty, brutish, and long.

Here’s my list of tips for wringing every ounce of benefit from a tracking tool. Not quite a cheat sheet, but close.

Use A Tracking Tool

Obviously. But I’ve worked on more than one project in which the manager declared “We’re going to track everything in this Excel spreadsheet”.

Do yourself a favor and go get whichever tracker works for you. There are tons out there, free and otherwise.

Write Good Ticket Titles

The title is a ticket’s headline. Like good email subjects, it should be informative and memorable. Your ticket will appear among tens or hundreds of other tickets. Make sure the title conveys the essence of the issue clearly.

Use words like “should”. Don’t use words like “broken”, “hosed”, or “problem”. You’re opening a trouble ticket. Those concepts are kind of a given.

Bad: Problem sorting last name

Better: Last Name Dropdown On Registration Screen Should Be Sorted Alphabetically

Bad: Can’t Buy a Man Purse

Better: Clicking “Buy” On Final Checkout Page Raises NotANumberError

Don’t Confuse Severity With Priority

It’s easy to think that something is of critical importance because it is badly broken. Remember, ticket priority is how important it is that the problem is fixed. Severity is how badly it’s broken.

Low Severity and High Priority:

We’re missing legal copy on the man purse checkout page. We could be sued by pursesfordudes.com for millions because of an obscure legal loophole.

High Severity and Low Priority.

The FAQ page that two people a week visit is totally broken.

Generally, severity is something measurable. It’s something most people should be able to agree to by observing it.

Priority is much more subjective, and the product or business owner is who usually sets this one.

Don’t Send Email

Don’t give into the temptation to send your own mail with the status of the issue or to get information about it. Any ticketing system worth it’s salt sends email, and plenty of it.

3 Reasons Tickets Are Better Than Email

  1. They keep a better history of the issue. Who did what and when.
  2. Tickets provide an Single Location for information on an issue and what’s been done about it. No chance for multiple mail threads.
  3. They leave no doubt as to who has the ball. Whoever is assigned the ticket is on the hook to do something about it or send it to someone who should (just keep an eye out for ticket ping-pong).

Insist On a Ticket

When someone has a problem but hasn’t opened a ticket, gently remind them to do so. This is hard to do without coming off like a jerk.

“Whaddya mean open a ticket? The Website is DOWN! We don’t have time for this!”

My favorite tactic for this is to say or email: I’m taking a look now. In the meantime please open a ticket and assign it to me.

These two sentences appease the reporter that immediate action is being taken, and at the same time reinforce the fact that a ticket should be opened. Works like a charm.

Act On Every Ticket

If you’re going to insist on a ticket, you need to keep up your end of the bargain. When an ultra-high priority ticket comes through, you need to jump.

For lower-priority issues, ensure they get attention or are given a proper burial. Bug scrub meetings are excruciating, but in my opinion essential tools for tending the garden of issues.

Once your users/business-owners realize their tickets get attention, they’ll use them more, and your life will get easier.


That’s my list. I’m all ears if you have other commandments that have worked for you.

[Tickets Image courtesy of basykes]

Be sure to check out From Python Import Podcast, a new Python-centric podcast hosted by Chris Miller, David Stanek, and Mike Crute. Definitely worth a listen.

From Python Import Podcast

Twin Ego Peaks

| Comments

Most software is complicated. Ask anyone who’s fallen in love with Rails doing rinky-dink tutorials over a weekend, only to be frustrated on Monday when applying the same technology to real-business problems.


Louis Brandy posted a double-peaked graph illustrating the confidence level of C++ programmers, Basically, early on you learn a little and think you’re hot stuff. After a while, you start to realize that you don’t know anything, and that there’s WAY more to the problem space than you realized.

Then it’s a long climb back to your initial confidence level.

Louis distinguishes between pre- and post-valley programmers. Assuming this chart applies to other languages (I think it does, with maybe some different amplitude), do you ever want pre-valley people? Does their confidence or bright-eyed optimism do any good, or does it just create false hope?

Never trust a programmer who says he knows C++ [lbrandy.com]

via The Endeavour