Why you don’t need a large development team to produce a high volume of quality work

Here’s an insight into a few principles I believe have got us to where we are today.

A developer’s ability to do their work efficiently doesn’t start and stop with them; good work management is essential to get the most out of a development team. Our work is a mixture of small maintenance jobs, adding features to existing projects, and building new projects from scratch. A single developer could be working alone or with three others, depending on workload and schedule.

At Ten4, the development team is free to decide the best method for managing their work. The system we settled on is Kanban.

Kanban is good at tracking lots of small jobs, and it encourages a steady flow of tasks moving through to completion. Splitting large jobs into small chunks means we can easily put multiple developers on one project, work on many different projects during the day, and react quickly if something urgent appears.

Once a developer has completed a task, their entire working memory can be emptied and applied to the next one without fear of ‘losing their place’. The alternative is mentally exhausting and a killer to productivity.

For these reasons, having well-defined tasks is absolutely necessary, and the development team holds project managers accountable for clear and thorough task definitions. Project managers know that well-defined tasks are the reason the development team’s schedule can be so flexible and reactive, so the incentive is there.

It’s tempting (especially for non-developers) to think that code is valuable, so more code must be more valuable than less code. In fact, our clients don’t come to us for code, they come for solutions to their problems, and the solution is where the value lies.

We’re only human, and every additional line of code we control increases the probability of a mistake being present. Every mistake becomes a problem that takes our time to investigate and resolve in the future. Constant bug fixing kills the momentum on existing projects and fills our schedule, meaning deadlines get pushed.

More code also means more documentation. Obviously documentation is very important, but when developer resources are constrained, it’s wasteful to throw hours at technical writing if you can avoid it. By minimising code we minimise the documentation burden accordingly.

With these points in mind, we will usually apply the solution to a problem that means the fewest lines of code are under our control. In practice, this means building on top of other platforms (like Craft CMS), using existing libraries where possible, celebrating the removal of code (when features are unaffected), and always weighing up options in terms of code liability.

If we could solve our client’s problems to an appropriate standard without writing a single line of code, we would.

If you don’t want your team constantly bogged down in maintenance and technical debt, your choice of platform is crucial. As a general rule, we never build client-facing work on young and unproven technology, simply because the support network isn’t in place, and we can’t guarantee the technology won’t suddenly be dropped by its maintainers next year and leave us with an unwanted rebuild scenario or security nightmare. A small team like ours can’t afford to waste time like that.

Picking a mature platform also means fewer inherent bugs, better compatibility with hosting environments, more documentation and third-party libraries available, and a larger pool of talent to employ from.

Only once the industry has generally embraced a technology, and there’s a reasonably developed ecosystem around it, do we consider it eligible for our own work. Even then, it’s important to recognise developer retraining might be involved, which may make the overall investment uneconomical.

At Ten4, the majority of our work sits on the tried-and-tested Nginx/PHP/MySQL stack. It may not be fashionable, but it just keeps quietly going. Maintenance is minimal, and we can benefit from our own custom hosting environment without needing dedicated server administration staff.

Having the right tools is a fundamental part of doing good work, and those of us in the programming profession are uniquely suited to delegating boring parts of our jobs to machines. This isn’t lazy, it’s common sense; humans should be doing the work only humans can do, and if your developers are performing mostly menial, mechanical work, you’re wasting a valuable resource.

At Ten4, any form of repetitive drudgery is rarely endured for long. We keep a modest suite of simple tools for automating project setup, SSL certificate management, database imports etc. that the entire team uses daily. On the other hand, we realise that code deployment is a solved problem. There’s no need to roll our own system and take on a pointless maintenance burden, so we delegate that responsibility to third-party software. If you don’t pick your battles, that fancy tool you made could end up costing you more than it saves.

All of our custom tools are single-purpose and succinct enough to be read and understood by all developers. If you don’t understand your tools you can’t repair them, and if you can’t repair something, you’re at risk of being incapacitated. Being incapacitated is, funnily enough, not conducive to doing good, efficient work.

There’s a common thread running through these principles; remove the obstacles to a developer’s productivity, and they produce more. Sounds obvious, but sometimes the obstacles themselves aren’t so easy to see.

Poor work management leaving your developers struggling to keep up; a large custom codebase only one person understands; ‘technical’ work that feels like development but could be easily automated; a technology that saps everyone’s time and energy fighting fires... these can all be signs your developers aren’t able to reach their potential.

Ten4 is certainly not perfect. But the health of our portfolio is testament to the value of applying these principles to a real-world development team.