I waste too much time relearning how to do simple things that only come up once or twice per year. Some recent examples:

• Figuring out how to build an AppleScript to show/hide hidden files. Every time I reinstall OS X I’m starting from scratch, with only a faint recollection that I once knew how to do this.
• Every time I modify my /etc/hosts file I completely forget how to flush my local DNS. Sure the answer is a quick Google search away, but it’s frustrating that I can’t just remember this.
• Once every 12 months or so I find myself needing to write a regex to truncate decimal numbers. This is trivial, but every time it comes up I have to spend thirty seconds thinking it through for like the tenth time in my life.

From this day forward, every time I learn (or re-learn) a simple task like this I’m going to document it on my blog. This is partially so that I can query my blog as a proxy for my past knowledge, but by making these little things public perhaps I can help somebody else also trying to relearn that little piece of syntax they once knew but forgot years ago.

Truncating Numbers with Regex

Today I was working with a JSON object containing SVG paths. The paths contain decimals with a ridiculous amount of precision and I needed a way to quickly truncate all of them at once. A portion of that file looked like this:

"frame" : {
"framePath" : "M 338.00358637178726,76.44431778009219C 337.3533534525326,76.44431778009219 328.2739344566734,75.22811129070296 319.67,74.15 C 317.50,73.88 295.21,70.88417372385919 293.094015386729,70.33711592961231 C 219.8144624861983,51.43448609977959 150.69444444444446,59.13249044730145 98.71787208607293,79.69548237636549 C 98.71787208607293,80.34571529562014 98.71787208607293,105.05456622729717 98.71787208607293,105.70479914655182 C 104.19818564217239,138.56241136723992 103.1188808312146,165.83046925594903 130.05909879414747,185.423355047173 C 171.04623388375416,215.2321805668871 230.55555555555557,210.52137933619036 259.1511450329329,197.25759417760776 C 274.12500192608155,190.31211676462385 284.23559266287486,174.83312522486972 297.3344728765868,163.7922732666347 ",
"nosePath" : "M 297.3344728765868,163.7922732666347C 300.61877960915047,157.71737810848663 299.45871165265066,156.9281764260582 303.90308634171424,151.64248295033855 C 312.8221414955163,141.03505334903969 324.94089906256886,132.40677608534708 338.00358637178726,131.06388299748352 ",
"templeProfilePath" : "M 103.39210998206816,86.42137601547572C 104.39210998206816,86.42137601547572 112.39210998206816,86.42137601547572 113.39210998206816,86.42137601547572 C 113.39210998206816,87.42137601547572 113.39210998206816,95.42137601547572 113.39210998206816,96.42137601547572 C 112.39210998206816,96.42137601547572 104.39210998206816,96.42137601547572 103.39210998206816,96.42137601547572 C 103.39210998206816,95.42137601547572 103.39210998206816,87.42137601547572 103.39210998206816,86.42137601547572 ",
"lensPath" : "M 304.6828883843359,94.28066353971869C 315.15242080095635,110.11085599156657 281.8913723752886,154.36727094138655 249.95695467226062,174.5634496818991 C 229.19157202630007,187.6960323215128 179.15619563044785,190.04204825863354 143.7124545468221,168.68589073225627 C 115.0311971938544,151.40437835918695 116.3066956065222,98.9434122137887 120.8796942175233,89.74067422456241 C 125.76091487574503,79.91766778910245 168.00571744139953,73.51652014971526 205.07771935487446,74.05426220951449 C 229.19157202630007,74.40404188517087 295.166110391501,79.8910593861534 304.6828883843359,94.28066353971869 "
}

So, I fired open my favorite text editor and built a regex to search for three groups in a row:

• (\d+\.): A group of one or more digits ending with a period, followed by…
• (\d{2}): a group of exactly two digits, followed by…
• (\d*): a group of 0 or more digits

Altogether, the full regex search is:
(\d+\.)(\d{2})(\d*)

I wanted to keep the results of the first two groups, and ignore the last group, so my regex
replacement looked like this: $1$2

I know. It’s hardly rocket science. But now that it’s documented I’ll save myself 30 seconds every six months.

After running the regex find/replace my JSON shrunk to just this:

"frame" : {
"framePath" : "M 338.00,76.44C 337.35,76.44 328.27,75.22 319.67,74.15 C 317.50,73.88 295.21,70.88 293.09,70.33 C 219.81,51.43 150.69,59.13 98.71,79.69 C 98.71,80.34 98.71,105.05 98.71,105.70 C 104.19,138.56 103.11,165.83 130.05,185.42 C 171.04,215.23 230.55,210.52 259.15,197.25 C 274.12,190.31 284.23,174.83 297.33,163.79 ",
"nosePath" : "M 297.33,163.79C 300.61,157.71 299.45,156.92 303.90,151.64 C 312.82,141.03 324.94,132.40 338.00,131.06 ",
"templeProfilePath" : "M 103.39,86.42C 104.39,86.42 112.39,86.42 113.39,86.42 C 113.39,87.42 113.39,95.42 113.39,96.42 C 112.39,96.42 104.39,96.42 103.39,96.42 C 103.39,95.42 103.39,87.42 103.39,86.42 ",
"lensPath" : "M 304.68,94.28C 315.15,110.11 281.89,154.36 249.95,174.56 C 229.19,187.69 179.15,190.04 143.71,168.68 C 115.03,151.40 116.30,98.94 120.87,89.74 C 125.76,79.91 168.00,73.51 205.07,74.05 C 229.19,74.40 295.16,79.89 304.68,94.28 "
}

From: Michael Righi
To: Joe Gallo
Subject: Git

Dear friend and business partner,

I’m writing to thank you for convincing me to replace Subversion with Git as our source control management (SCM) tool. At first I resisted the change, but after making it past the learning curve I realized that Git is the best tool for managing changes to our source code. It makes it much easier for developers to collaborate than any other tool I’ve tried. This thing rocks!

My previous experiences with SCM tools were with Visual Source Safe, CVS, and Subversion, which all rely on a central repository. Git’s distributed approach was initially very alien to me, but things made more sense once I realized that Git is to source control what Napster was to music: a peer-to-peer tool for sharing files. With Git, each developer’s computer has a complete copy of a software project’s history, and teammates can send each other new code by transferring it directly from machine to machine.

The best thing about Git is its blazing fast speed! Subversion would sometimes take ten minutes to merge two branches of code, but Git’s merges only take seconds. Instead of getting a cup of coffee while my code merges, now I barely have time to check my email before it’s done. At first I assumed that only black magic could explain a speed increase of that magnitude, but now I realize that Git is so fast because of how it stores changes to files: instead of copying the entire codebase when a branch is made, Git only stores the incremental changes. And unlike Subversion which compares the differences between files over the network, Git can do the comparison on the local hard drive. Very clever.

Do you remember that time my computer crashed after I opened an attachment from the Nigerian prince who needed help wiring $10M into the country? I couldn’t decide if I should be more upset that I lost all my data, or that I lost out on making a quick million! What unfortunate timing for my hard drive to crash just as I opened his email. Anyway, at least I didn’t lose any of my work in the Java project I was developing, because I was able to restore my code from GitHub.com, the online Git hosting service you recommended.

Another benefit of Git is that it lets me code while flying, because it doesn’t require a live network connection the way Subversion does. Since Git can operate as a standalone tool, I’m now able to branch and merge my code at 30,000 feet! This was a lifesaver on my last flight when a bad-breathed accountant wanted to chat my ear off about tax law. I told him to go bother the Subversion developer in aisle twelve because I had work to do!

I’ve been encouraging my friends and customers to learn more about Git at its official web site, http://git-scm.com/ . When they ask how much it costs I explain that Git is free and open-source, so the only cost is the time it takes to learn it.

Thanks again for the great recommendation!

Take care,
Michael

P.S. I was finally able to track down that Nigerian prince, and would you believe he still needs my help wiring the $10M? Can I borrow $5,000 to cover the transaction fee? Everything is explained in the attached file, EasyMoney.pdf.exe.

A fashion trend has been growing over the last few years, and I saw it widely displayed on a recent stay in New York: the decorative man-scarf. On a warm day in Central Park, my girlfriend and I calculated the percentage of men wearing a decorative scarf, and it would only be a slight exaggeration to say that it was 150%.

Personally, if I wanted a stylish way to keep my neck warm I’d rather grow a mullet than wrap a plaid tablecloth around my neck. That said, it’s difficult to tell which clothing trends will stick, and I wonder if the future will make me look like a fashion fool. In twenty years will our skies be filled with flying cars, decorative man-scarves fluttering from the windows? Are man-scarves more like MC Hammer pants in the 1980s, or denim jeans in the 1880s?

Exiting Central Park, we caught a brief glimpse of the trendiest man to ever walk the earth. Except he wasn’t walking the earth, because he was riding a Segway…while wearing a decorative scarf. Never before had I witnessed such a powerful intersection of fashion and technology trends.

This chance encounter got me thinking about two things: First, technology is much like fashion in the sense that it’s hard to predict what the future holds. Second, how awesome would it be to use a Segway as a segue in my next TEQ article?

I love working with new technology, and I’m fortunate that my job as a software developer allows me to do this often. However, working with the latest tools comes at the expense of sometimes learning a technology that quickly becomes abandoned and obsolete. (WML, VRML, and J# come to mind.) Employing the newest technologies also prevents me from being able to apply all of the experience gained from my last project to the next one, because by the time one project wraps up there are new tools to learn.

My team and I recently started developing condominium management software. Our previous project lasted fourteen months, and many tools were released in the interim for us to consider adding to our tool chest. It was a challenge deciding which new technologies to adopt, which old ones to upgrade, and which to abandon altogether. We took into consideration our knowledge invested in the old tools, the benefits of alternatives, and how likely it would be for the technologies to still be around in a few years.

Nothing was sacred, and we even considered replacing Java (our staple language) with Python. Although we’re sticking with Java, some things we’ll be using are very new to us, such as EC2 (Amazon’s Cloud Computing service), Git for version control (in place of Subversion), and Spring 3.0 as our application framework on top of Java.

Mispredicting the future of technology is costlier than getting it wrong with fashion. A silly looking scarf might set you back $40, but investing in a dead-end technology can cost you years that you’ll never get back. Worse still, it can leave your company entrenched in obsolete solutions that are hard to maintain or replace. Performing due diligence can help prevent this situation, but I don’t trust my prognostication skills to rely on them alone. That’s why we architected our software in a decoupled and layered manner that will allow parts to be more easily replaced. (Like swapping a scarf for a necktie while keeping the pants and shirt.)

In future articles I’ll describe the decisions we made for this project, and since we’re still in the early stages I’ll get to share realtime updates along the way. The choices we made are leading us down an unfamiliar road, but hopefully you’ll enjoy reading about the adventure. By the end I’ll probably be pleased with some decisions and come to regret others. Who knows, maybe in a year you’ll even spot me zipping away from Barnes & Noble on a Segway, with a scarf rippling from my neck, and a Python book in tow.

My grandfather enjoyed a simple lifestyle in upstate New York, so when he passed away last year there were only a few accounts in his name that needed to be closed. One was with his telephone provider. Usually when people talk about their “telephone provider” they mean “telephone service provider”, but not so with Papa. My grandfather leased a rotary phone for $1.75 per month rather than buying his own for $10. The phone he was given in 1967 served him well until the end. Over the years my family tried to convince him to join the modern world of touchtone telephone ownership, and along with it the ability to express your language preference with the press of a button. But my grandfather, bless his soul, sometimes preferred consistency over common sense.

If Papa were here today, and if he owned a computer (ha!), and if he had an Internet connection (double ha!), there’s no doubt in my mind which web browser he’d be using: Internet Explorer 6.

IE6 is to web browsing what a rotary phone is to calling. It’s ancient (IE6 was released in August, 2001), it’s slow (today’s browsers can render pages in half the time), it’s full of security holes (as of February 9, 2010, Secunia.com lists 24 unpatched vulnerabilities in IE6), and it simply can’t do all the whiz-bang things that modern browsers can.

I used to have a handsome head of hair, but it’s been replaced by a – some would say more handsome – bald dome. The cause? Genetics, and more than eight stressful years of crafting web sites to display correctly in IE6. Ask any web developer what the hardest part of their job is, and they’ll probably tell you it’s devising tricks to get IE6 to properly display pages. For nearly a decade, web developers have wasted countless hours struggling to fix IE6-specific problems. Their time could have been better spent creating new features, learning new techniques, or grooming the hair they’d otherwise still have.

Last month my company got bit by an IE6 bug in software we built for a customer. Our application turns form letters into PDFs, and it displays a list of the most recent documents on a page that we call the Print Queue. The page features a checkbox next to each document, and two buttons at the bottom: Print and Delete. Depending on which button is pressed, our software either prints or deletes the chosen PDFs. Unless you’re using IE6. In that case it always deletes the documents, even if you hit print. Yikes!

When you submit a web form, your browser is supposed to tell the server which button you clicked. But when IE6 sees a form that contains multiple <button> tags, instead of telling the server which one was clicked, it recklessly submits the name of every button on the form! Imagine if our nuclear missiles were controlled by a web page with two buttons: Disarm and Launch. Let’s just hope the Russians are using Firefox.

Last month was my tipping point. Instead of wasting an hour tweaking things for IE6, with my customer’s consent we completely blocked access to Internet Explorer 6 and lower. Time and hair are just too precious to be wasted on such problems, and fortunately I’m not alone in this belief. Google recently announced they will begin phasing out support for IE6 this year, and they are part of a larger movement to do the same. Although IE6 still accounts for 20% of web traffic, campaigns such as BringDownIE6.com are working to change that. Despite what you might think, these efforts aren’t anti-Microsoft. Although I prefer Chrome and Firefox, IE8 is a decent browser too.

If you’re reading this article I suspect you already stopped using IE6 years ago. But if you’re still developing web sites for it, I hope you’ll join the movement and abandon this hideous browser. Should you disagree, there’s this phone company in upstate New York I can highly recommend.

If you were given the opportunity to travel back in time for one day, how would you use it? Would you try and stop a famous tragedy? Would you go back to witness an historical event, like the Beatles’ first appearance on Sullivan? Maybe you’d prefer to relive your happiest day.

For me it’s a no-brainer. I’d use the time machine to go back six months and stop myself from using SOAP in my last software project.

Last year my company developed warranty management software for a company that makes siding for homes. Our application manages most of the claim process from filing to payment, but one part it doesn’t handle is the scheduling of the home inspection. A third-party handles that step, and they have their own application that my team’s program had to interact with.

To get our applications talking, we decided to use web services with SOAP. It made perfect sense. After all, our situation was exactly the kind of data-exchange-over-the-web type of application that SOAP was designed for. We’ve used it before, and although we’ve never loved it, it still seemed like the best tool for the job.

But what started out as a two-week task turned into three months of debugging, handwringing, and self-doubt. Nothing worked as it should. First our Java application couldn’t connect with the proprietary authentication technique the other company was using. (Although SOAP itself is a standard, it can work with dozens of “sub-standards” which aren’t all well supported.) Then we had problems with decoding image attachments, data validation, XML file size limitations, and server conflicts with other programs. At one point the web service even failed when the other system’s clock fell out of sync because of daylight saving time.

SOAP’s not an acronym anymore, but when it was, the “S” used to mean “simple”. Ha! That’s like calling a cystoscopy a “simple procedure”. Sorry Dr. Smith, but what you once described to me as a simple procedure is actually the least simple thing I can think of. And the only thing more painful was that time I used SOAP in a warranty management application.

SOAP has good intentions, and with enough effort it can be made to work well. But the problem with SOAP is that it’s built on top of many layers, and with each new layer comes a new set of complications. SOAP tries to be an all-encompassing protocol, and although this makes it powerful, it also makes it complex.

Fortunately there’s an easier way of exchanging data between programs over the web. It’s called Representational State Transfer, or REST. Unlike SOAP which is a protocol, REST is more of a general approach to sharing data between a client and server. A RESTful web service forgoes complicated protocols, and instead takes advantage of HTTP’s underutilized features.

Imagine you run a business that rents camels by the hour. In addition to allowing reservations on your web site, you want to open your system to third party brokers. The brokers use their own software to compare prices and make reservations, and they’re not going to rent out your camels if you don’t give their software a way to hook into yours. You decide to make your reservation system available to theirs via a RESTful web service.

With REST, you expose your software’s functionality via meaningful URLs, and you take advantage of HTTP’s “verbs”, which are called actions. For example, if a broker wanted to check the availability of your two-humped camels, their software could issue a GET request of http://www.carav.an/camel/hump/2. To make a reservation for a camel named Gobi on April 12th, their software could issue a POST request of http://www.carav.an/camel/gobi/2010/04/12. To check on the status of reservation #123, they could issue a GET request of http://www.carav.an/reservation/123, and to cancel that reservation they could issue a DELETE request of the same URL.

Unlike SOAP which is limited to XML, RESTful web services can share their data in any number of formats, such as XML, JSON, or CSV. REST replaces complexity with simplicity, and it takes better advantage of existing methodologies instead of inventing its own. Although it lacks some of SOAP’s strengths, such as a unified way of defining your interface, it makes up for it with its ease of implementation.

The next time you develop a web service, consider this alternative to SOAP. Although we can’t travel backwards through time, at least we can use REST to save it.

This is an actual email I once received from a friend:

Date: October 27, 2005
From: (I’ll protect the not-so-innocent)
To: Michael Righi
Subject: number

071-89122

That’s it. Nothing more to see. Just a vague subject and a mysterious number.

The email probably made sense at the time, but today I have no idea what question it was answering. And what kind of number is that? It’s clearly not a phone number, and it doesn’t follow any common patterns like credit card or SSN. Maybe it’s a numbered Swiss bank account I forgot I had.

This email suffers from a lack of context, but that’s not to say it didn’t have any at the time. The problem is that the context was likely provided by a phone conversation I was having with my friend. I’m guessing it went something like this.

Me: “Hey, I forget the number for the XYZ. Do you know what it is?”
Friend: “Sure, check your email. I just sent it to you.”
Me: “Got it! Thanks!”
Friend: “Anything for you. You’re such an awesome person, Michael!”
Me: “And you’re a great judge of character!”

Contextless emails are one of my biggest pet peeves, because they’re confusing and unsearchable. My email archive represents the collective knowledge of everything that’s passed through my inbox since 1996, and I’m constantly searching through it. What’s the phone number for the plumber I hired five years ago? Where does my customer like to play golf? Which bondsman does my attorney recommend? All of these questions can be answered with a quick search.

I rely on email searches so much, that I often send emails to myself with information I might need one day. Here’s a recent example:

Date: October 1, 2009
From: Michael Righi
To: Michael Righi
Subject: Rachel is Allergic to Buckwheat

Rachel is allergic to buckwheat. It will kill her. Quit offering her food that has buckwheat in it, like multigrain pancakes or anything from Kashi. She’s starting to think you’re doing this on purpose.

Keywords: allergy, allergies, buckwheat, buck wheat, allergic reaction, Rachel, EpiPen, benadryl, ways to kill my employees

I can never remember what Rachel is allergic to, but now I can do a quick search to find out.

When I send emails to others, I don’t go as far as adding keywords in the message, but I do provide context with descriptive subjects and message bodies. Instead of sending an email that says, “Their number is 412-271-9293”, I’m more likely to say, “The phone number for Beasley Plumbing is 412-271-9293.”

Not everyone is good at writing descriptive emails, but fortunately tools exist to make their emails searchable anyway.

Apple Mail is my main email client, and I use a plugin called MailTags. ( $29.95 from indev software ) When I receive an email with little or no context, MailTags lets me add my own keywords for quick searching in the future. This is especially useful for emails with PDF or image attachments that couldn’t otherwise be indexed.

Outlook users might benefit from Taglocity, which offers email tagging and more. Although I’ve never used it myself, I’ve heard good things, and I encourage you to learn more at http://www.taglocity.com/.

Gmail calls their tags labels, and you can even create filters to automatically assign them, such as “attachment” to emails with attachments or “family” to emails from certain addresses.

These tools are great, and I recommend you use one, but the best solution would be for everybody to start sending more descriptive emails from now on. As Rachel will tell you, this isn’t just a matter of convenience. It’s a matter of life and death.

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.

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.

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.

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.