Partial knowledge and unfinished work: the pitfalls of solo working

It’s a common belief that working alone, in the quiet, on individual tasks is most efficient. This is probably true when the work in question is truly independent, and the worker doesn’t need the skills, knowledge or approval of others. In such cases, solo work seems perfectly reasonable; if that’s your situation, congratulations!

However, this is seldom the case. Work which is expected to be done solo tends to be dependent and partial: partial in that it cannot be completed by one individual, and dependent in that it’s normally a small cog in a wider project. Solo is perhaps the worst possible way to get such work completed.

Partial knowledge and delayed workflows

How many files or lines of code do you have intimate knowledge of - and what percentage of your company’s total code base does it represent? Do you know 10% of the system? Perhaps 0.1%?

Consider the skills required to take a feature from a concept all the way to deployed software in the hands of user: to name a few it needs UX design, UI design, technical architecture, data management, security, testing, automation, deployment, monitoring...

Do you suppose that each soloist has even 40% of the skill and experience required to complete the entire task?

Because they are armed with just a fraction of the full system knowledge and a partial skillset, a solo worker is making a change that will have to be reviewed and integrated by other people. It may then need to be tested and approved by an entirely different set of people.

The trouble with overcommunication

Working alone in a large company often means you don’t know exactly who has to be informed about the changes you need to make to a given piece of software. This means you have to broadcast status updates through email, slack groups, messaging, and maybe a wiki or Confluence document store. You must over-communicate to ensure everyone who needs to be updated is updated, and so must your peers.

Additionally, the work is never finished when it leaves your desk. Instead, completion status is distributed across several developers, making it difficult to track - and every ticket with your name on it is an invitation to being interrupted.

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

When the work you do is (half) finished

While one piece of work is being reviewed, approved, or tested, 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 or haven’t been deployed yet.

How long will items wait in queues for review, approval, and testing? In a corporate environment, a two-day programming task may wait in queues for weeks. If something is returned for rework, it will have to go through all the queues, approvals and reviews yet again.

That makes the completion of any partial task wholly unpredictable - which adds up to make every whole project that’s been divided and distributed unpredictable too.

Another queue, another delay, another interruption

If a piece of work is returned, reworking it will have a knock-on effect and delay the other jobs you have in your queue. This is true of every single person in the organisation who is working on dependent, partial projects.

The system itself ensures constant interruptions and delays. Status reports are uncertain and disjointed; completion of any feature is easily interrupted and deferred by other features’ needs; work waits in queues for approvals and reviews rather than flowing smoothly to production, and waits again after reworking.

Why do we have a system that so determinedly obstructs this flow?

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

Simple: no one is perfect. Each developer possesses only partial system knowledge and a specific subset of the skills necessary for a given project. This mean that no one person is able to produce an entire feature, resulting in a disparate collection of individuals each working on different aspects – and individuals make mistakes. Every code submission is potentially flawed. We have to catch these mistakes, so we add gates and reviews and inspections to stop some of the bugs from ‘going live’ - but we slow down the whole process to do so.

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

Through informal queries I have found that in most corporate shops, 60-80% of all work done by programmers is defect removal. People program as fast as they can to meet deadlines, but then have to rework the code to actually make it functional – therefore threatening all the further scheduled deadlines.

Speed up the process by working slower

If code was always correct when submitted - even if it took more than twice as long to write - and it always worked without defects, the whole process would be faster because the incessant queues, delays and returns most programming teams see would be unnecessary.

Individual work does keep individuals as busy as possible - but it does so at the expense of clear, trackable status, swift completion, and reliable schedules. Additionally, these exceptionally busy individuals are 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. More time spent on employee development would result in higher quality output.

But isn’t this just the price you pay for having a corporate programming organisation? What could you possibly do instead?

Start together, work together, finish together

Instead of splitting the work among individuals, individuals could be assembled into teams to do the work. They can start together, work together, and finish together.

If insight and skills are pooled through collaborative working, each project has access to 100% of the skills and systems knowledge needed to complete it effectively. The result will be less ‘work in progress’ (resulting in fewer interruptions and less over-communicating), clearer status of projects, and a massive reduction in delays created by the work’s tedious progression through queues and approvals.

It’s expensive to make mistakes, hunt them down, and then interrupt ongoing work to fix them. Pooling expertise and using techniques such as ensemble programming and test driven development (TDD) can greatly reduce the number of errors as well as allowing a team to learn to avoid making more.

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