June 2008 Archives

Can you write a test that does more harm than good?

In the intro to his upcoming book The Art of Unit Testing, Roy Osherove describes a case where poorly-designed tests actually hurt his team’s progress:

Worse yet, some tests became unusable because the people who wrote them had left the project and no one knew how to maintain the tests, or what they were testing. The names we gave our unit test methods were not clear enough. We had tests relying on other tests. We ended up throwing away most of the tests less than 6 months into the project.
I’m on the fence. Anything that exercises your code in a automatic, repeatable way has got to be useful. On the other hand, poorly written tests cost time and effort to understand, refactor, and fix.

Are the drawbacks to bad tests worse than having no coverage at all?

I think  the answer is that in the short term, even bad tests are useful. Trying to squeeze a extra life out of them beyond that, however, pays diminishing returns.

Just like other software, your tests should be built for maintenance, but in a crunch, you can punch something in that works. It’s better to have bad tests than to have untested code.

(photo courtesy of Still Burning, some rights reserved)

Nice Links

| Comments

If you’re fighting the signal to noise ratio in your feed reader like me, you’ll enjoy having A Continuous Learner’s Weblog on your reading list.

Steve Pietrek (an Ohio boy!) collects handy links almost daily and posts them up. There’s a definite lean towards .NET stuff, but also a lot of quality web and programming links.

How to Work With...er...Girls

| Comments

In my interweb ramblings, I came across this gem of an article that helps us male programmers bridge the gap to working with female developers.

Have we finally got the Time Machine working? Is it 1986 again?

Seriously, if you need a manual for working with the opposite sex beyond “Don’t be a jerk. Be normal” you have bigger issues. We’re all professionals here. If anything, building software lends itself to more gender equality than other jobs.

Results count in our business. We notice successful work before checking if it was a man or a woman who produced it.

My advice is that we all grow up, be normal, and do work.

[link] The Invasion of the Female Programmers (You Might Have to Work with One)

Inspirational Favicons

| Comments

Ticket Mail Isn't Spam

| Comments

Automated ticket emails aren’t annoying spam. They can be very handy if you manage your inbox and issue tracker the right way.

Back in my consulting days, we used a different issue tracker for every project. Sometimes it was dictated by what the client already had installed, sometimes the project picked one. Sometimes bought, sometimes homegrown.

Regardless of the specific tool, people always complained about “ticket spam”. After the initial notification scheme was set up, there was an endless cycle of tweaking to exclude people from the CC list in certain cases, include them in others, or remove them completely. Configuring the ticketing system became it’s own separate project. Ultimately many people started ignoring the mail entirely, relying on logging in to the tool to see what was happening.

Looking back, I think the problem wasn’t the notification scheme, but how people were managing their inboxes.

Ticket mail is useful. It’s a way for an issue to broadcast it’s life to the world of interested parties. It eliminates the need to send someone a separate email to ask how things are going or to get a status.

The problem is that you don’t care about most ticket mail. Most ticket mail you could ignore forever, some you’d like to see at least the subject line, and some you need to know about immediately. The trick is to manage your inbox to accomplish this.

Set up a rule to send messages that probably don’t need your direct attention (like tickets that aren’t assigned directly to you) to their own folder. Check in on them from time to time to get a bird’s eye view of what’s going on.

Tickets that are assigned directly to you should go to your inbox, just as if a person had sent you an email about the problem.

If the issue has a high priority, configure an alert so that it really grabs your attention. You want to be notified immediately of tickets that require your attention while less important ones go on the back burner.

In the end, you want people to pay attention to ticket mail. This actually reduces the load on your inbox. You won’t have any more messages titled “What’s the status of that login issue”, or “RE: Progress on ticket 2992399”.

The Noisy Channel recently had a post linking to this article on how Google measures their search quality.

When Google tries new ranking models, these metrics sometimes move, sometimes not, and never by much. In fact Google does not use such real usage data to tune their search ranking algorithm. What they really use is a blast from the past. They employ armies of “raters”  who rate search results for randomly selected “panels” of queries using different ranking algorithms. These manual ratings form the gold-standard against which ranking algorithms are measured — and eventually released into service.

Who knew? I suppose it makes sense. Yahoo! started out as human-managed lists of “quality” links, and the human brain is pretty sweet. It’s nice that the people can still sometimes kick machines in the butt.

A righteous code_swarm for Python.

code_swarm - Python from Michael Ogawa on Vimeo.

There’s been a bit of chatter over the recent NPR story about email overwhelming people’s time in the workplace. The trendy news angle seems to be to convince us that email addiction and information overload is a serious problem, worthy of the attention of high-powered think tanks to help save us from drowning.

That’s like saying there’s a problem with people’s bathtubs overflowing. The problem isn’t too much water, its that they didn’t turn off the tap!

  • If you feel like you spend too much time in email, turn off Outlook and Gmail for an hour.
  • Getting pulled into thirteen different IM chats at a time? Close your messenger for a whole day.
  • Keeping up with online news bogging you down? Unsubscribe or unclutter your feeds .
The solutions are simple. You don’t need fancy mail managers, tools (this one lets you send from Gmail without viewing your inbox ), or data management systems. You just need to be responsible and focus on your work.

I once worked with a guy in an email-intensive office who had an Outlook rule set to permanently delete any mail not directly addressed only to him. Amazingly, he didn’t get fired, and was regarded as one of the most productive people on the team.

We are not the victims of information overload. We’re victims of our own lack of discipline.

We’re human beings. We run the world. We’ve split the atom. I think we can handle our own inboxes.

I know it can be hard to unplug from the stream of information. Lots of things are hard, but we still have to do them. It’s sometimes referred to as being a professional.

Traits of Unit Tests

| Comments

A while back Michael Feathers wrote a short post about optimizing unit tests. In it he gives a list traits that prevent something from being a true unit test.

When trying to convert non-testers, I often use a reverse version of Michael’s list to help explain what is a unit test. So here’s the same list with a positive spin:

A test is a unit test if :

  • It doesn’t talk to the database
  • It doesn’t communicates across the network
  • It doesn’t touch the file system
  • It can be run at the same time as any of your other unit tests
  • You don’t have to do special things to your environment (such as editing config files) to run it.
Of course there are more qualities. Think of this as a list of traits as necessary but not sufficient for something to be a unit test.

Generated from the front page of Code Softly.

John Rockefeller posted his Top 5 Firefox Extensions for Web Developers. It looks pretty good. I find #3 a little on the bubble, though. The Google Toolbar already shows PageRank, but maybe searchstatus is a better use of real estate.

This meeting smell happens when someone from the technology team asks “Do you want…”.

“Do you want the user’s session to continue after they leave the site?”
“Do you want us to optimize that for search engines?”
“Do you want auto-complete in the search box?”

These are bad questions because they don’t convey what’s really being asked: “Is this feature worth our time and effort?”.

What the business owner hears is “Should we include this sweet feature that will make you look good?”. Their answer is almost certainly yes, but they’re not answering the real question.

The real question is “How important is this feature?” This conveys the idea that the tech team wants to focus on essentials. It also reminds the business owner that not all features are created equal.

I wrote before about how stating “I want” is a good smell. The difference is that it’s OK for the business owner to declare “I want”, but not ok for someone to ask “Do you want?”. It’s leading the witness.

Every time you ask someone if they want an awesome feature the answer will be yes. The real information comes when you ask how badly they want it.

Soft Links: My People

| Comments

Here are some bloggers I know personally. Check them out, yo:

When I get around to adding Code Softly’s blogroll, they’ll be on it.

I Hereby Claim this Blog

| Comments

I’m claiming Code Softly on Technorati.

They give you two ways to do this. One is to provide your blog’s username and password.


That seems like a bad idea, so I’m opting for the second way, writing a post with a link to my Technorati profile.

(This is also a great place to remind you to share the sweetness you find here with the ShareThis widgets you see on every post. It’s greatly appreciated. I’ll be your best friend).

I saw a flamebait of a post today that’s fairly critical of the agile direction software development is taking .

Finishing it, I realized that it was either some kind of sarcastic rant or egotistic power trip, but it got me thinking. Doubting, even.

“Why is Agile Better?”, I asked myself.

Why do managers allow technology groups do a 180 on how they build things? I mean, imagine if a construction company told you they were going to build and finish your house a single room at a time. You’d probably punch them in the face.

I started doubting myself.

“Maybe traditional waterfall monolithic IS the better way.”
“Maybe we’re just lazy wimps”.
“Maybe agile is just a fad, like Hypercolor”.

Finally I took a deep, calming breath. I remembered why managers let us do agile-ish things. Risk.

Risk is what convinces managers to do agile, whether they know it or not.

I’m not saying there aren’t other good reasons, but no manager is truly concerned with your personal comfort while programming. They don’t care how happy you are or how bleeding edge your methodology is. They only care that the project is done on time and that their boss is happy.

I’ll prove it. When was the last time that you had a looming deadline and your manager said, “Aw, let’s just move the live date back a few weeks. I don’t want you getting all bent out of shape and stressed out. Your comfort is more important than a silly deadline”? It’s a manager’s job to care about results, not comfort or fun.

Arguments about “It’s more in tune with how people work”, or “It’s nimble”, don’t really resonate with managers. But risk, there’s something that makes their ears pick up.

Managers love to manage risk, and agile helps. It lowers the chances of a live date arriving with nothing ready for launch. Agile helps get the most important parts production-ready first. If the entire development team is struck by a single Bus Of Doom and wiped out, the project can still launch with the highest priority features complete. This gives managers warm fuzzy sensations they aren’t used to feeling ( because of the risk avoidance part, not the dev team being wiped out ).

Classical waterfall stinks at mitigating risk. Everyone has experiences to back that up. The project that’s perpetually 90% complete. The Case of the Missing Fifty Pages of Requirements. The Gotcha from Hell. All these are cases where the big day comes around and there’s absolutely zilch to show for it. That’s risky.

If you have a superninja waterfall strike team, then waterfall might be just the thing for you. If you’re like every shop I’ve ever worked for or heard of, you’re praying for some agile, any agile, to kick in and save you. I say play the risk card and see if the managers take the bait.

My First Big Link!

| Comments

My post about sane development estimates is getting a lot of nice traffic from being linked at dzone (thanks Rick!).

If the mood catches you, please hop over and give it a vote. Thanks!

173510300_cd2491ae82_m.jpgThis second installment of Meeting Smells is a catalog of sweet smells. These are some key phrases that are good to hear in a requirements meeting. If you have any meeting smells of your own to offer, fair or foul, I’d love to hear about them in the comments.

“I Want”
This is the essence of a requirement, but business folk often sugar coat this with phrases like “is it possible to…” or “can we..”.

Many engineers give the smartass response, “Anything is possible. How much time and money do you have?” Don’t say this. It’s confrontational and makes you sound like a jerk.

Requirements are all about desire. Desire to make new things. Desire to make better things. Don’t stifle that creative energy.

Let people ask for the sun and the moon: “I want a shopping experience that faster than our competitors’ “, “We want to process all three million records before the next billing cycle”, “I want a webserver on the moon”.

“Requirement” is such a harsh term, we should call them Desire Meetings.

I use this one all the time to de-rail attempts to architect the project in the requirements meetings. It’s very easy to begin solving problems as soon as possible, and so requirements meetings very often turn into debates over implementation.

Whenever someone asks me a question like “Will we host this with our current billing provider”, or “Can this go into a spreadsheet somewhere, right?”, I simply answer, “maybe”.

You have no idea what the best solution is going to be this early in the project. Discussing details at this point is almost irresponsible. A noncommittal answer reinforces the dynamic nature of things at this point. Bite your tongue and be vague.

“I Get The Idea”
You don’t need every detail in requirements meeting. The goal is communication, not accounting. If you understand what the business owners are driving at, you’re fine.

Nobody can predict the future, so pressing for details at this point breeds conflict. Besides, the answers you get will be invalid in a week, when everyone changes their mind. Try to understand the overall business goals. You’ll find yourself anticipating the business’s needs before they ask. It’s like magic.