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.

The economic meltdown is causing devastating effects for millions of people, and I’ve witnessed its collateral damage first hand. Some of my smartest, hardest working friends — people that I used to consider untouchable — now find themselves unemployed. Even the most fiscally prudent and financially conservative people have been harshly impacted by the incredible scope of the stock market and housing crashes. Unlike in the past, you didn’t have to be reckless with a credit card, buy a Miami condo with no money down, or risk your life savings on a dot com IPO to be impacted this time around.

I’m fortunate to live in Pittsburgh, because my city has not been affected as badly as other places. BusinessWeek labeled Pittsburgh one of the best places to ride out a recession, Smart Money magazine called Pittsburgh a recession-proof place to retire, and the New York Times said that Pittsburgh is the envy of many recession-plagued communities. In short, Pittsburgh is an awesome place to be in a horrible economy.

That said, if Pittsburgh is one of the least affected cities in the country, I can only imagine how bad things are elsewhere.

My grandfather — we called him Papa — was a big believer of investing in the stock market as the means to a comfortable retirement. When I was ten years old, he helped me purchase my first shares of a publicly traded company, and when we spoke he’d often dispense stock advice. To Papa’s delight, he met CNBC anchor Larry Kudlow at an airport a few years ago. “Michael,” he would later recount, “this man wore the sharpest pinstripe suit you’ve ever seen!”

Papa passed away two months ago, and although his death was an immensely sad and difficult thing to deal with, in a small way I am happy that he didn’t have to live out his final years struggling to get by. In just a few months, his investments lost more than a decade’s savings, and I don’t know what he would have done had he lived another twenty years.

My grandfather’s generation was sold on three ideas which my generation — I’m twenty-seven years old — has trouble believing today. The first is that investing in the stock market for the long term is the best way to save for retirement, the second is that climbing a corporate ladder is the surest way to success, and the third is that social security will be there for your golden years.

Between October 2007 and March 2009, the Dow Jones Industrial Average dropped more than 50%. I am still a believer in free market capitalism and the American economic engine, but I know that this crash has shaken the confidence of many of my friends. Tomorrow morning my company is rolling out its first retirement plan in the form of a Simple IRA. Although most of my employees are in their mid-twenties, and despite their knowledge that it’s best to buy low and sell high, some of them are hesitant to trust the stock market after what’s happened lately. Personally, I’ll be maxing out my IRA, but it’s difficult to blame them for lacking faith.

Another evaporated belief is the notion of climbing a corporate ladder to a comfortable retirement. Gone are the days of joining a company like General Motors with an entry level position, and counting on the business to take care of you for life. Many people my age couldn’t explain to you what a pension fund is, or for that matter how it differs from a mutual fund. Workers of my generation have had stability replaced with insecurity, and endurance replaced by transience.

So much doubt has been placed on the future of social security that many people my age just assume we’ll have none. Social security strikes me as a pyramid scheme that could only be stable in a world where life expectancy decreases while child bearing increases. (Octomom to the rescue!)

Faced with an unpredictable stock market, a non-existent corporate ladder, and an unlikely social security payout, I have never been more at peace with my decision to be an entrepreneur.

As an entrepreneur, I have much more control over my destiny than I would if I worked for somebody else. The stock market’s success is influenced by swings of emotions outside my control, while my company’s success is influenced by the quality of service I provide my customers. This I can control.

If I were an employee of a large business, my corporate ladder could be kicked out from underneath at any time. But, in the words of former Pittsburgher Paul Graham, as an entrepreneur I can grow a corporate ladder underneath me instead of climbing someone else’s to the top.

And when it comes to retirement, rather than relying on my government for socially offered security, I feel more comfortable depending on myself.

Of course, being an entrepreneur has its drawbacks too. Two weeks ago I worked eighty hours in seven days, and in addition to worrying about putting food on my plate, I enjoy the added stress of anguishing for my employees too. Don’t get me wrong; it’s not all roses.

Despite the stresses of being an entrepreneur, I’m much happier to be running my own company in today’s economic climate than I would be working for somebody else. Past and present employees of some large companies (Lehman Brothers, Bear Stearns, and AIG come to mind) must feel like hapless passengers aboard the Titanic. However, being an entrepreneur in a small business is like being the captain of a small speed boat. It doesn’t make the waters any safer, but at least you’re in control of navigating them.

I was actively involved with the Cub Scouts as a child. On one of our camping expeditions, a troop leader taught us how to start a fire by rubbing sticks together. (To be honest, he tried to teach us how to start a fire with sticks, but in the end nobody — not even our group leader — was able to achieve ignition.)

We began by searching the woods for two dry sticks that were “thicker than our thumbs and thinner than our wrists.” After locating the ideal timber, we sat in a circle and listened to the leader explain the process of starting a fire. Well, some of the kids listened. Eager to see flames, I was too impatient to hear the instructions and began furiously rubbing my sticks together. My troop leader, dismayed that I wasn’t paying attention, asked me to stop. He set down his sticks and asked all of the kids to do the same. Seizing the opportunity, our leader took a moment and shared the story of the Magpie’s Nest.

The Magpie’s Nest is a story from the late 1800’s, published by Joseph Jacobs in English Fairy Tales. More parable than fairy tale, the Magpie’s Nest tells the story of how different birds learned to build their nests. Here’s an abbreviated version of the tale:

All the birds of the air came to the magpie and asked her to teach them how to build nests. For the magpie is the cleverest bird of all at building nests. So she put all the birds round her and began to show them how to do it. First of all she took some mud and made a sort of round cake with it.

“Oh, that’s how it’s done,” said the thrush; and away it flew, and so that’s how thrushes build their nests.

Then the magpie took some twigs and arranged them round in the mud.

“Now I know all about it,” says the blackbird, and off he flew; and that’s how the blackbirds make their nests to this very day.

Then the magpie put another layer of mud over the twigs.

“Oh that’s quite obvious,” said the wise owl, and away it flew; and owls have never made better nests since.

After this the magpie took some twigs and twined them round the outside.

“The very thing!” said the sparrow, and off he went; so sparrows make rather slovenly nests to this day.

Well, then Madge Magpie took some feathers and stuff and lined the nest very comfortably with it.

“That suits me,” cried the starling, and off it flew; and very comfortable nests have starlings.

So it went on, every bird taking away some knowledge of how to build nests, but, none of them waiting to the end.

My troop leader was making the point that you should always be patient when learning something new. If you run off and start applying new knowledge too early, it can come back to bite you. Sometimes you’ll even be downright dangerous putting partial knowledge to use. (Imagine trying to fly an airplane after reading a manual for an hour.)

I often think of the Magpie’s Nest when I deliver corporate training seminars. Some of the courses that I teach are prerequisites for other classes, and I worry that my students will be overconfident with the partial knowledge that I’m able to share in just a few days.

For example, in Introduction to Java I teach students how to connect to a database with JDBC. Unfortunately, I can only afford to spend four hours on this topic in a typical five-day course. This is plenty of time to explain the basics, but not nearly enough time to cover good style and best practices. I do my best to explain that in the “real world” developers should consider using a database pooling manager, a JNDI registry, and even an Object Relational Mapping framework such as Hibernate. These are all topics that I teach in more advanced courses.

I do my best to emphasize that what I’m teaching is a necessary prerequisite but a horrible real-world practice. Despite my emphasis, I still worry that students will act as I once did, and start rubbing their sticks together too soon.

It’s a difficult problem to solve. On one hand, I believe that a solid foundation needs to be laid before students can learn best practices. On the other hand, I fear that my students will never get around to learning more robust techniques. Part of my fear is fueled by ego. I worry that a person who knows better might see the handiwork of one of my students and ask who taught them how to build such shoddy software. (I also worry that their software will be slow, inefficient and insecure, but I’d be lying if I said egotism didn’t play a large role.)

I’ve learned that the best way to solve this problem is to set realistic expectations. When I begin to deliver a new topic that I know I won’t have time to cover deeply, I simply explain the situation. I tell my students that the topic they are about to learn is complex, and that we won’t have time to discuss all of its nuances.

After covering the topic as well as time allows, I ask my students to come up with ideas for how they could improve upon what they learned. Rather than explicitly pointing out the shortcomings of what I just showed them, I believe it’s important for my students to realize them on their own. I want them to understand that it’s important to learn more about the topic before they go to work. If they arrive at this conclusion on their own, then they will be more likely to take the initiative to learn more.

This advice applies to teachers and students alike. Trainers should set realistic expectations, and put their students down the path toward learning more. Students should be patient as they learn, and resist the urge to apply their knowledge too soon. Impatience is often a sign of passion, and passion is great for learning. However, it’s important that passion be channeled and patience be exercised when learning something new. Remember the tale of the Magpie’s Nest, and don’t rub your sticks too soon.