“OK, let’s start coding!” However exciting these words are, they are far more comforting when it won’t be you who has to do all the work to kick everything off.

Consequently, starting a software project is a real divider between the experienced senior and the eager junior — and so I recommend that tyro devs get very familiar with all the areas that need to be covered, then have a go with a project that doesn’t have too many eyes on it. Many decisions can be delayed, and certain things can be trivially changed without any side effects, but some items are more expensive to alter later. This post is about where to start, and what bits are best to get right early on.

What Good Looks Like

The number one killer of all projects — even those that are not scrutinized in any way — is that their worth cannot be measured. Even little habits you start for yourself, like going to the gym or starting a diet, get quietly dropped if you see no measurable progress. In industry, unmeasurable projects may look good, but they have an inbuilt kill switch because you cannot prove how they add any value. Remember all those slightly annoying surveys you got in your inbox asking you questions about a website or service you just used? These are people making a solid effort to measure intangibles like “knowledge share.” However hokey it is, try to build a measurement track into your project from the start. There are various things to measure, from early adoption, to unique page views. Conversely, you can measure the decline in a bad thing your project is trying to prevent.

Keeping an up-to-date project wiki   is the key to stopping early problems from spreading because of unclear aims. Write down what the project should achieve, the basic components you think are needed, who the stakeholders are and, yes, a few target dates. Novel situations will always occur, and people will do the wrong things — and frankly, some of the decisions you make early on will be faulty. None of these cause chaos. That is caused when people don’t share a strong enough idea of a project’s direction with anyone else. Just writing enough down is quite easy to do, and stems a lot of doubt.

The MVP and the Fakes

The first thing you produce or build should just be in the shape of what you need, but little else. If the product is a website, then it should match the format you want, but just be filled by a “Lorem ipsum” placeholder filler. What matters is that the MVP (minimum viable product) forces you to focus on the infrastructure you need to get in place.

Do you need access to an expensive service? Are you charging money? Is your service time-dependent in some way? In almost all cases you will need to fake one or more components of your project in order to test it, without invoking real-world costs or conditions.

Sometimes quite a bit of work is needed to create the fake environment, but that must be done. For example; while it is much easier to charge money than it used to be, we’ve all seen services that try to introduce charging only to discover that it isn’t so easy to plug in later (because of all the previous assumptions)