A “one developer project” — with great freedom comes great responsibility.

If you find yourself in this situation, what should you do to ensure that the next developer can pick up where you left off? (Bearing in mind this developer could be you sometime in the future!)

What’s wrong with a one developer project?

In a typical software house environment, a delivery team might comprise a couple of developers, a tester, a devops guru, some form of analyst and a “project manager”. (Quotes in place due to “agile” sympathies…not getting involved in that discussion here!)

That’s a lot of hats to wear for one person and a lot of knowledge to retain (or frequently Google!).

I’ve worked with people who have been able to juggle these roles. They are few and far between. Specialities are inevitable. Dislike of certain areas are too.

So, what can go wrong?

There’s often such a focus on delivery, that documentation, unit tests and code reviews disappear without a trace. Short term, this won’t be a problem…just wait for the call 2 months after go live when the customer wonders why the site has gone down.

The perceived cost savings of having a 1 dev team are clear to see. What happens when they go off sick or on holiday? No one knows anything about the project, the status of it or what the developer was thinking. Handover notes were long since thrown out by the cleaner.

Another set of eyes can often spot issues and propose simpler, more maintainable solutions. Code-blindness can easily set in when it’s just you staring at the same method for hours on end, second guessing yourself.

What should you do if there’s no choice?

One word: discipline. Run the project in a way that you would be happy to inherit it.

discipline: the practice of training people to obey rules or a code of behaviour, using punishment to correct disobedience.

To be clear, I’m definitely not advocating physical punishment here…the maintainability headache should serve as punishment enough!

What does discipline mean here?

In something of an order of preference, but entirely non-exhaustively:

• Use source control (git being the defacto standard these days)
• Code with standards enforced (amongst others resharper, stylecop in C# projects)
• Document progress & technical decisions (including any dependencies needed to make it work, maybe even taking copies if they’re super important)
• Ensure the project builds regularly on a build server somewhere (not just your machine!)
• Set up and document regular meetings with the client where you demonstrate progress (changes of priority and direction happen!)
• Ensure you’re tracking time/effort spent on the project. This might be important for getting “rewarded”, whether that’s payment or some other compensation.

Are these projects really so bad?

I’ve painted quite a bleak picture so far. Things aren’t all bad.

You could treat your one developer project as your favourite side-project - meaning you get to choose the language, the frameworks and the infrastructure. You’ll inevitably learn new skills.

You’ll get to interface directly with the client (if it’s not your favourite side-project!) - there should be less chance of confusion or ambiguity around requirements.

You’ll not have any distractions from (now unnecessary) meetings. Delivery might even be quicker due to no merge conflicts, database change synchronisation or enforced design patterns.

You’ll have to stick to your estimates (& budget) and deliver.

Would I recommend it?

Simply put, no. I believe that during it’s lifecycle, a project needs input from a variety of disciplines, all of which have complementary effects on it’s chance of success. Left to one person, luck plays more of a part than I’d be happy with.

What’s been your experience of one developer projects? Let me know in the comments.

Thanks for reading.

(first published on Medium here on 25th Feb 2019 (pre-ai revolution!)) https://medium.com/@adrenalinehit/one-dev-projects-4ed9d23c3afa