Several times in my career I have lived the engineer's dream. A brand new project. A clean sheet of paper. New team. New technology. Although in each case the goal, and the technology, and the people were different, these projects all had one thing in common. They were sheer Hell.

Oh sure, a clean sheet project is wonderful challenge, a great way of stretching technical skills, a new start. But the first phase of every really new project is always the same: chaos. Nobody knows what exactly we were supposed to be doing, but we all know we need to do it in a great hurry. The tools are unfamiliar. Half of the team is frozen in indecision half the time, while the other two quarters are working overtime to duplicate each others' work. The infrastructure is missing or changing daily.

I don't know how you start up a new project painlessly, but I do remember a few things that helped:

Get the infrastructure up now

You just can not develop software effectively without a little bit of infrastructure, and the longer you wait to install it, the harder life will be. Get git set up on day one. Follow this rapidly with an automated build system. The best automated build system you can create is the one that is in place before there is any code to build. Ditto with those mailing lists: the first day someone sends a email to the acme-developers list suggesting we all go to lunch is the day you start to have a team. A wiki and a bug tracking system are not quite so critical, but why not stand those up while you are at it?

Now is not the time to build a framework

Tony Hoare is usually credited with uttering the classic bit of wisdom that "Premature optimization is the root of all evil." Well if that is so, then premature frameworks are the stems of all evil. Or maybe the leaves.

The early days of a project are difficult for coders and one reaction is to run away, run far away into the well defined land of building a framework. I say framework building is well defined, because, well, it is usually the engineer, as opposed to the real customers, that do the defining. I see we have some tough GUI problems here, let me go off and build a framework to solve them. Left unspoken is, And I get to stop thinking about all this hard and confusing stuff and do something fun.

The problem with this is that if you don't really understand the basic problem you are trying to solve – and early in a project you don't – then that framework you are building is unlikely to help. Leave the frameworks until you know where you are going, until you really have code that is duplicated and you know that if you step back and take a longer view, you can do better.

Frequent, short meetings

Reread the title of this section again. Pay special attention to that second word. S-H-O-R-T. There is a tendency early in projects to mete out death by meeting. If we are all ignorant and confused, let's get together and talk about it for six or seven hours. That will help.

The main problem early on in the project is that on any given day, each person will discover one more piece of a 10,000 piece puzzle. What you all need to do is to get together and share your pieces. But if you stay in the room for four hours or even one, you are taking up valuable piece searching time. Get together, show off your colorful new piece of the puzzle, and then get back out there and start prospecting again.

Don't change everything

I think it was Fred Brooks in The Mythical Man Month – a book written a very long time ago and still worth reading – who introduced the idea of the second system syndrome. This happens when engineers start over with a new system and are just dying to fix everything that was wrong with the old one. All this old junk, these old techniques, that old library, and certainly that ugly GUI, they all have to go. And it's not just the coders either: SSS can infect the configuration management folks – God I want a new bug tracking system – as well as technical writers – Let's do all of our work on Chromebooks for the new project!

These may all be great ideas – or not – but do them all at once and you will spend the first 80% of your schedule making the bug tracking system generate bug reports in the right format for the release notes because bug reports you will have aplenty. Most successful follow on projects focus on a few key goals and drive relentlessly towards them. By keeping things some things the same you build on one of the key things you gotten out of that first project: experience. Build on that experience. Make sure you have some familiar tools and technologies in the mix. Don't always say no to new ideas, but don't always say yes either.

Walk the halls

If you are any kind of leader in a new project, anything from a task lead on a two person project, to the manager of bit development team, and you are not talking to your folks daily, you are doing it wrong.

And I don't mean email. Nor IM. I mean face to face. Or at least camera to camera. If you don't occasionally suspect that Fred wore that same shirt yesterday, you aren't doing your job. The problem with a new project and new technologies and a new team is that everyone is in unfamiliar territory. You are either dealing with people you don't know, or people you do know who are dealing with a project they don't fully understand. Either way, the chances of miscommunication are high.

Don't believe me? Imagine you walk into Bob's office and ask him how his project is going. Bob, who obviously didn't get much sleep last night, shifts in his chair, looks at the floor, rubs his face and says, OK. Now imagine you walk into Sally's office and ask the same question. Sally leans back in her chair, picks up her triple vente hazlenut latte, flashes you a big grin, and says OK. Now imagine sending Bob and Sally an email: How's your project going? Same answer in both cases: OK. If you really want to know what is going on, get out there and talk to Bob and Sally.

There you have it. No silver bullets here today, but sometimes you need to say the obvious because the obvious is so frequently obscure. To get a new project started you need infrastructure and you need it quick. Don't let anyone run off to framework land too soon. Get the folks together for frequent, short meetings, and keep some of the underpinning familiar. Finally, escape from your important Microsoft Project work every day and check on how the actual project is doing.

Next time we're going to look at how you keep your team together and constantly pushing towards the finish line.

– Russ