Every one of us has a pet project archive. It could be software we started and saw partway through but never quite finished. It could be code that began strong but came to a screeching halt because more pressing issues came up. Other work got in the way, or we simply lost interest.

Pet projects fail when there are no time constraints and nothing is on the line if we don’t succeed. When a launch date is “one of these days,” we likely won’t be finishing it anytime soon. Some of us seem to spend years mulling over that next great idea instead of first deciding on a specific amount of time to build it.

How about just three months? Jack Dorsey spent less than that from initial concept to launch of the first version of a little-known SMS messaging service that later would be called Twitter.^[5] Imagine if, instead, he had spent years and years on development instead of the short burst from start to launch. Things might have turned out differently.

Timing Is Everything

That’s why time is the most important parameter in maintaining a passion for writing software. With a pet project, it’s fine to start writing code for amusement and learning. However, when we’re ready to turn it into something real, we need to define our time boundaries. Answering the following turns a project into something real:

• How much time will I spend working on this project each day, and how many days will I spend each week?

• When can I show a mostly ready product to someone else?

• What day will I launch this to the public?

• What day will I release my first major iteration?

The first question creates sustainable, daily expectations. Maybe it’s just two hours a day and three days a week. It just has to be consistent. From 3 p.m. to 5 p.m. each afternoon is better than “whenever I find a gap in my schedule.” Spread it evenly too. Mondays, Wednesdays, and Fridays might be a better set of days to work than lumping all three days over the weekend. That leaves too large a gap between sessions, and you’ll waste a lot of that extra time refreshing your memory about where you previously left off. Finally, make your schedule achievable. Making a habit of saying “I’ll put it off today and make it up tomorrow” gets stale really fast.

The second question gives us a deadline for test-ready software. It’s a stake in the ground: a short time from now where our co-worker, friend, or spouse gets a crack at what we’ve done. It helps us to work backward to figure out how much time we need to do our work between now and then. Couple this with how much time we spend per day and week, and we’ll know how much time we need to do every coding session.

The third question gets us ready for “good enough” software, which is software that has all the big things right and is ready for the general public. It’s launch-ready. The time between the previous date and this one is where we fix the bugs that are critical to get right, not the hundreds of minuscule feature additions we all want but can live without for a few weeks.

And that’s where the answer to the fourth question comes in. It sets us up for everything after launch. We’ve launched, and now we need to set up a time to push new releases. Perhaps it’s a week after launch or less. Because it’s web-based software, it can be just a few days (or even hours) after launch. Once we actually have gotten to this stage, we’re off and running.

These time constraints create the walls we need to fill in with work. It helps us define our most important features. It gives purpose to each moment we put into our software. Without rigid time constraints, we can go on noodling forever wondering whether we’ve made something just right. Instead of getting ready to deliver something, we’ll be tweaking each step for as long as we please. Productivity dries up when we don’t have that sense of urgency. Time constraints keep us progressing.

Set a Deadline, Even If It’s Arbitrary

Our company’s first product, DoneDone,^[6] began as one of my pet projects. DoneDone is a simple web-based, bug-tracking tool that focuses on clarity and a simple workflow over complex features. I started writing it because we didn’t like the other bug tracker we were using that was costing us $120 every month. It was gaudy in places we wanted less. It was missing some small things that would’ve made our process more efficient. I knew I could do something better. If we were willing to pay for our current bug tracker, others would certainly pay for this.

For the first few weeks, I worked with only ideas. No wireframes or specs. I just wrote code, built interfaces, tested, refined, and wrote some more. I was still in the honeymoon period of development. Though I was directionless, the thought of making money off a product was enough motivation to start.

Fast-forward a few months later. It was November. Client work began to pick up again, and naturally, my pet project got shuffled to the back of the priority line. Every few days, I might carve out a couple of hours to build DoneDone, but those hours were sluggish and unproductive. Most of my time was spent reacquainting myself with what I had done before. Because those time periods weren’t consistent, it was hard to decide what I should work on when I suddenly found myself free.

Instead, I needed a new approach. As a business, we had to treat DoneDone with the urgency of a client project. What was the difference between this project and projects we’d done for other clients? It was simply that we were our own client. And just like a client project, we needed dates: a date to release DoneDone internally, a date to launch the product to the public, and dates to release iterations thereafter.

In the end, I decided we would launch DoneDone on April 15, 2009. Perhaps there was some poetic connection with the fact that it was the same day the IRS collects our taxes. Frankly, it was just an arbitrary date, about six months away, that felt like the right amount of time—not too much, not too little. There was a lot of work to be done, but if I used 50 percent of my workday on DoneDone and brought in a couple people to pitch in every now and then, we could get this project off the ground. A pet project suddenly became a real project.

With a deadline set, we could fill in that time with a requisite amount of work. We needed to add the payment gateway, figure out our cost structure, build a marketing site, and clean up our feature set. Everything had a time and a place. That sense of urgency—and productivity—came back.

After we launched, there were certainly other features to add. Looking back on it, it’s hard to imagine DoneDone ever not having them. We did not have an email-to-ticket system or a tagging system for issues, both core pieces of the product today, but they simply weren’t mission-critical for launch. We focused on the most important features that a bug-tracking tool that took six months to build would require. Over the next ninety days, we released ten new updates of DoneDone.

Have I really written a whole essay about setting deadlines? Yes. In all its unrevolutionariness, it’s amazing how having a hard date in your head is the difference between work that gets done and work that escapes into La La Land. Deadlines keep your work relevant. When you let your project bleed from months into even years, your product might not have the intended worth it had when you began.

Deadlines create a sense of urgency that gets you to the finish line. They give you the push you need even if you have no one else breathing down your neck.