Note: This article originally appeared in the October, 2009 edition of TEQ Magazine.

This summer, a friend and I walked the length of Manhattan for my birthday. Our goal was to trek the fourteen miles from Battery Park to 220th Street, and depending on how things went, return by subway or ambulance.

We estimated a six-hour walk, and periodically checked our progress along the way. But tracking a Manhattan hike isn’t easy, because the numbered streets don’t begin until after you leave SOHO. If you’re as Vitamin-D starved as I am, that could mean you already have serious blisters before 1st Street.

A few blocks past Times Square, my cell phone rang. It was another friend, and she wanted to know what time to expect me for dinner. Having already passed the naked cowboy, I told her I didn’t think I’d be much longer. After all, isn’t Times Square just a couple blocks south of Harlem? (Fact check: They’re as distant as Squirrel Hill and Monroeville.)

That day I realized that long walks are like big software projects. It’s hard to measure their progress, difficult to predict their completion, and both can induce big sweats.

In my last column, I discussed techniques to measure the quality of your code, and in this issue we’ll look at ways to measure your progress during development. But first, a note of caution: This stuff is hard to do well. Even companies like Microsoft and Apple aren’t perfect, so start by lowering your expectations. In fact, I would go as far as saying that on the spectrum of awful to awesome, the best companies only score slightly higher than “doesn’t suck.”

Have specific goals.
Many projects fail from a lack of planning. If the project is large enough, it should have a written specification, which may include use cases, technical specs, and functional specs. Without a clear goal, how can you know when you’re done?

Break up your goals.
Predicting the duration of a project is like guessing how much sand is in a desert. That’s why projects should be divided into sub-tasks, each representing major sections of the software. Keep breaking sub-tasks into smaller sub-tasks, until you’re left with fine-grained tasks, all with time estimates under forty hours. It’s easy to imagine what can be accomplished in a week, but difficult to do the same for a month or a year. Now you’ll be counting the sand in a jar, instead of a desert.

Measure with metrics.
Many project management applications exist, but I’ve had the most success with these two tools:

Google Spreadsheets – This is the easiest and most affordable solution I’ve used. Create a row for every fine-grained task, and set up columns for task name, original time estimate, current time estimate, hours worked, and hours remaining. Add some logic to turn the completed tasks green, and share the document with all parties involved. This takes thirty minutes to set up, it’s very easy, and it’s very free. Try it out at http://docs.google.com

FogBugz – FogBugz is a bug tracking and project management application from FogCreek software. It features evidence-based scheduling, which allows you to predict how realistic your milestones are based on the track record of every member on the team. The Burn Down Chart shows how much time remains before goals are reached, and FogBugz even demonstrates which tasks stand in the way on the critical path. FogBugz costs $25 per user per month.

Update your metrics often.
Donald Rumsfeld once said, “There are known unknowns, but there are also unknown unknowns. [These] are things we don’t know we don’t know.” This quote is often taken out of context and applied to war. Of course, Rumsfeld was actually talking about software development. Scope creep happens, and surprises are common. Metrics are only as useful as the data you provide them, so don’t be afraid to update numbers based on knowledge gained along the way. Updating your metrics at least once per week will keep you and your projections honest.

Whether you’re building software or hiking through New York, it’s difficult to predict the future. But, with proper planning, fine-grained sub-goals, and a little technology, you’ll stand a fighting chance.

As for my Manhattan hike, we finished in just over seven hours, and I made it to dinner on time. I gained a new respect for the size of Manhattan, and the importance of better planning. Next year, I’ll attempt to walk the length of Pittsburgh’s Golden Triangle in a day. My prediction: Twenty minutes, including a stop at Primanti’s.

Note: This article originally appeared in the August, 2009 edition of TEQ Magazine.

Older brothers can be very cruel to their siblings. Just ask my little sister. As kids, we often split the chore of washing the dishes after dinner. I dreaded this task, but one evening I had some fun with it at my sister’s expense.

After enjoying our mother’s chicken tetrazzini, I raced to the sink to wash my half of the dishes first. But instead of washing the dishes to perfection until half remained, I carefully washed 50% of every single dish in the sink. Each plate resembled a half-moon made of Parmesan cheese and chicken skin. Hilarious.

Sure, if I had done the job properly it would have taken less time, but you should never underestimate the wicked dedication of an older brother.

The moral of my story is that work assignments and job performances can be measured and interpreted in different ways. This is especially true with software projects.

As a software developer, I am commonly asked how “big” my applications are. (The cheeky side of me wants to answer with a physical size. “Well, I once built an iPhone app that was 2×3 inches!”) In all seriousness, when I’m asked this question I assume the person wants to hear about the scale of my software, so I tell them how long it took to build, how many concurrent users it can handle, and how large the underlying database is. Interesting stuff if you’re trying to gauge a developer’s experience, but what if you want to measure the progress of a project under development?

Some programmers measure their progress by counting how many lines of code they’ve written, but this practice makes me taste my lunch again. Why? First, the numbers aren’t isomorphic across different languages. (Twenty lines of C++ might accomplish the same as five lines of Java, or one line of Ruby.) Second, measuring progress by counting the lines of code encourages the development of bloated software. To quote Kanye West quoting Daft Punk, I’ve seen many applications that would be “harder, better, faster, stronger” if they were rewritten with half the code.

Last year this issue became an important one for my company. During negotiations with a client, I proposed that our fee be split into thirds, with the second payment due after three months. However, my customer wanted to cut the second check when “half the software was complete.”

But what does “half the software” mean? Half the lines of code? If so, then we’d have to somehow predict the final line count in advance. Since our software was web-based, it was suggested that we measure the number of pages built, but even that’s not perfect. If 75% of the pages are 65% complete, is that considered half? Besides, when web applications are measured by page count, developers are rewarded for building clunky user interfaces that use more pages than necessary.

Fortunately, I was able to convince my customer that “half the software” was too vague, but others aren’t always so lucky. I once saw a project whose members were unwittingly encouraged to ignore problems, because their success was measured by the number of bugs filed. If there’s no Dilbert cartoon for that, there really should be.

Good software developers view their work as a craft, and their software as a work of art. To them, judging software by silly metrics makes no more sense than judging the beauty of a painting by the canvas size, or the strength of a bridge by the number of rivets.

Instead of using lousy software metrics, companies should focus on what really matters: software quality. Yes, this is harder to measure because it’s more subjective, but it can be done.

What makes software good? For starters, good software isn’t bad, and bad software is easy to identify. Some of the many things that can make software bad include a lack of comments, poor formatting, mismatched naming conventions, copy-and-pasted code, deprecated method calls, and broken syntax that doesn’t even compile.

Just as it can be difficult to smell your own B.O., sometimes it’s hard to recognize when your own code stinks. That’s why my team uses an open-source Java application named Hudson. Hudson is a continuous integration tool, which is a type of program that automatically compiles, tests, and analyzes software on a recurring basis. Think of Hudson as a friend who sniffs you once an hour and tells you when it’s time to reapply the Old Spice. (To my fellow geeks: Old Spice is a form of deodorant.)

Once an hour, Hudson downloads and attempts to compile the latest source code for my team’s software projects. It then runs our code through a gauntlet of unit tests to ensure that our latest changes haven’t broken anything. Next, Hudson sends our source code through another tool named Checkstyle, which analyzes the code against a set of known bad practices.

In the end, Hudson generates a lovely web-based report that spotlights our projects’ health. Each project is summarized with an icon, showing either a shining sun for the really healthy projects, or a stormy thundercloud for the projects that should be taken out behind the shed. Clicking a report reveals more detail, including which unit tests failed and why, along with beautiful graphs that highlight the results of Checkstyle. For each issue, you can drill deeper into the reports to discover the source of the problem, along with suggestions for how to fix it.

Hudson is extremely customizable, and it does a million things I haven’t mentioned here. There are also many other tools available for measuring the quality of software, but Hudson and Checkstyle are the ones my team prefers.

I’ll admit that Hudson does a better job of telling you when software is bad, rather than telling you when software is good. For this I think you’ll always need code reviews and the opinion of an expert human being. Also, measuring the health of a project doesn’t really help you track its progress, so please don’t use tools like Hudson for this. Measuring the progress of a software project is such a difficult thing to do, that I’m going to revisit that one next time.

Project managers and developers, please stop measuring code with silly metrics.
At best they provide useless data, and at worst they encourage good people to do bad things. Instead, focus on measuring the health of your software and improving its quality. And if you’re still not convinced, just ask my dad about the time he asked me to mow half the lawn.

You can learn more about Hudson at http://hudson.dev.java.net , and Checkstyle at http://checkstyle.sourceforge.net.

Special thanks to Joe Gallo for editing and contributing to portions of this document.