Small teams and interruptions

It’s hard for non-programmers to understand just how bad interruptions are when it comes to being a productive coder. While most jobs suffer from the same problems of “getting back into the flow” after being interrupted, programming is especially difficult as normally programmers are trying to hold a number of structures in their head at any one time so as to solve whatever problem it is that they are working on.

In most small companies, the development team is might only consist of three or four people and in such a small team with a large backlog to deliver, it’s not normally the teams size that is the main factor in being able to deliver large amounts of work, but all the small interruptions that happen during daily business. Asking a developer that is sitting close by about when a feature will be ready or whether something can be fixed/changed is all too tempting and easy to do. Why IM or email when you can just shout across the room. It only takes a few 10-20 second interruptions to change a productive three to fours hours into just maybe one or two.

Once a company grows these sorts of problems can be smoothed out by having someone act as a barrier to the developers, shielding them from minor questions/requests and letting them continue with their work until free to discuss them. Small companies don’t have the luxury of assigning someone that role so need to find other means to minimising that contact. It’s important that someone sets some ground rules. It could be as simple as there is a set period of time every day that programmers should not be disturbed or communication should be limited to IM and email if possible. Just removing the constant stream of “Is X ready yet?”, “Did you get a chance to look at Y?” or “Would it be possible to do Z?” would mean a huge productivity boost for your programmers and overall deliverables for your company.