Starting a new software project? Don’t start coding right away.

It’s always fun to start a new project. I should know; I’ve been a consultant since 1995, and have started hundreds of projects of various shapes and sizes.  It’s tempting, when I first meet a new client and come to an agreement, to dive right into the code, and start trying to solve their problems.

But that would be a mistake.

More important than code, more important than servers, more important than even finding out what problems I’m supposed to be solving, is the issue of communication.  How will the client communicate their questions and problems to me?  How will I tell them what I am doing?  Even more importantly, how I will I tell them where I’m having problems, or need help?

Before you begin to code, you need to set up two things: First, a time and frequency of meeting.  Will it be every day at 8 a.m.?  Every Monday at 2 p.m.?  Tuesdays and Thursdays at 12 noon?  It doesn’t matter that much, although I have found that daily morning meetings are a good way to start the day.  (When you work on an international team, though, someone’s “morning” meeting is someone else’s evening meeting.)  These meetings, whether you want to call them standups, weekly reviews, or something else, are to make sure that everyone is on the same page.  Are there problems?  Issues?  Bugs?  New feature requests?  Is someone stuck, and needs help?  All of that can be discussed in the meeting.  And by setting a regular time for the meeting, you raise the chances that when something goes wrong (and it will), there will be a convenient time and place to discuss the problems.

I’m actually of the opinion that it’s often good to have both a daily meeting (for daily updates) and a weekly one (for review and planning).  Whatever works for you, stick with it.  But you want it to be on everyone’s schedule.

The second thing that you should do is set up a task tracker.  Whether it’s Redmine, Trello, GitHub issues, or even Pivotal Tracker, every software project should have such a task tracker.  They come in all shapes, sizes, and price points, including free.  A task tracker allows you to know, at a glance, what tasks are finished, which are being worked on right now, and which are next in line.  A task tracker lets you prioritize tasks for the coming days.  And it allows you to keep track of who is doing what.

Once you have set up the tracker and meeting times, you can meet to discuss initial priorities, putting these tasks (or “stories,” as the cool agile kids like to say) in the tracker.  Now, when a developer isn’t sure what to work on next, he or she can go to the task tracker and simply pick the top things off of the list.

This isn’t actually all that hard to do.  But it makes a world of difference when working on a project.