Previously published by the
British Computer Society.

There is a ubiquitous, unquestioned belief that it is most efficient for people to work alone, in the quiet, on individual tasks.

This is probably true when the work is truly independent and whole, and the people in question don’t need the input, review, skills, knowledge, or approval of others. In which case, solo work seems perfectly reasonable and fine. If that’s your situation, then congratulations.

It is very seldom the case. Solo work tends to be partial and dependent. Solo is perhaps the worst possible way to get partial, dependent work completed and deployed to production.

How many files or lines of code do you, as a developer, have intimate knowledge of and what percentage of your company’s total code base (all services and apps in an offering) does it represent? Do you know 10% of the system? Do you know 0.10% of the system?

What are the skills required to take a feature from a concept all the way to deployed software in the hands of user? Consider the UX design, UI design, technical architecture, data management, security, testing, automation, deployment, and monitoring. Do you suppose that each soloist has as much as 40% of the skill and experience required?

Armed with a tiny fraction of system knowledge and a partial skillset, you are making a partial system change that will have to be reviewed and integrated by other people. It may also be tested and approved by an entirely different set of people.

Why isn’t it obvious that this is risky?

If you are in a company and working alone, do you know exactly who has to be informed about each of the changes you need to make to the software? If not, then you probably have to broadcast status updates through email, slack groups, messaging, and maybe a wiki or Confluence document store. You must over-communicate so you don’t miss anyone who needs to know what you’re doing.

Likewise, your peers also overcommunicate in order to be sure that they’ve advised everyone of any interesting or upsetting change they have had to make.

It’s how people cope with individual work in corporate settings. It is also why everyone’s email and messaging system is overflowing and notifications are constantly interrupting you all.

While one piece of work is being reviewed, approved, tested, etc you have other work that you can do to avoid being idle.

You’ve probably contributed to many features and epics (possibly dozens) with the tickets you’ve completed, but those features aren’t complete and deployed yet.

When the status is distributed across several developers, it’s hard to track. It invites a lot of questions about when things will be done. If only the work was finished when it left your desk, it would be much simpler – but no; it is dependent and partial.

Do you realize that every ticket with your name on it is an invitation to being interrupted? People may have to talk to you about your work on top of all the other over-communication.

And speaking of when things will be done, how long will items wait in queues for review, approval, and testing? In a corporate environment, a 2-day programming task may wait in queues for weeks.

It’s worse if something is returned for rework, though, because it will have to go through all the queues and subsequent approvals and reviews again. That makes the completion of any partial task unpredictable, which rolls up to make every whole task that’s been divided and distributed defy prediction.

If work is returned, there is a knock-on effect: reworking it will delay any other jobs you have in your queue. Worse, it’s true of every single task for every single person in the organization who is working solo on dependent, partial stories.

The system itself ensures that you will have many interruptions, that status will be uncertain and distributed, that completion of any feature may be easily interrupted and deferred by any other feature’s work, and that all of the work we do will wait in queues for approvals and reviews rather than flowing smoothly to production.

Why do we have a system that prevents the flow of change to production? Easy! Remember that each developer has partial system knowledge and a subset of the skills necessary to produce working changes in production. Because we are sometimes (usually) insufficient for the work of producing whole features, and because we’re doing partial and dependent work, we make mistakes. Every person makes mistakes, so every code submission is potentially flawed. We have to catch these mistakes, so we add gates and reviews and inspections. These inspections may stop some of the bugs from “going live” so we slow down all of the code to catch the defects that would otherwise flow.

Deming once said, “let’s make toast the American way: I’ll burn it, and you scrape it!”

I have done informal queries and have been told that in most corporate shops 60-80% of all work done by programmers is defect removal. People program as fast as they can to produce code according to scheduled due dates, but then have to rework the code to make it work – which threatens all the scheduled deadlines.

If code was always correct, even if it took more than 2x as long to write, perhaps if it took 5x to produce, and it always worked without defects, it could flow to production many times faster because it would not have the queues and delays and returns most programming teams see.

Yes, individual work does keep individuals as busy as possible. It does so at the expense of having clear status, rapid completion, and reliable schedules.

Also, though, you have individuals too busy to help or teach each other. This means each person needs to self-train in their off-time or just make do with what they already know. There is precious little on-the-job training.

Isn’t this just the price you pay for having a corporate programming organization? What could you possibly do instead?

Instead of splitting the work among individuals, maybe try assembling the individuals to do the work. They can start together, work together, and finish together.

You’ll have less work in progress, the status of the work will be fairly obvious and the work will not have to flow through queues and approvals. If the people pool their insight by working together, you have 100% of the skills you need and a much broader systems knowledge.

Lower WIP means better throughput, fewer interruptions, and less over-communicating.

It’s expensive to make mistakes, hunt them down, and then interrupt ongoing work to fix them. If you can pool your expertise and use techniques such as ensemble programming and TDD, you can greatly reduce the number of errors AND you can focus on learning to avoid more of them as a team.

Is it a perfect system? No, but compared to solo work on partial, dependent tasks it’s far more efficient and manageable.