Dealing with not my-code-related issues

Question

In many programming projects that I develop, it happens that I hit a "wall", which it is not related to my code. The wall is some unexpected issue that prevents my project from working. It can be a hardware issue, it can be a system issue, it can be an issue that is related to some other code which I can't see.

What happens next is a long process of trying to fix/bypass an issue that it is not related to my code, and that I usually have no idea how to deal with. This process can take undetermined amount of time, and is usually very frustrating, because I have to deal with something that it is not related to my expertise, but it still prevents my project from working.

So I try to find the experts in the area, I try to make changes in the different system components. Sometimes it helps, sometimes it doesn't. Anyway something always feels wrong in these situations.

I want to ask 2 things about it:

1. Does it happen to most of programmers, or is it just some specifics of my work?
2. Are there any good strategies to deal with these situations?

Thank you.

Answer 1

Programmers deal with issues that effect their work outside of code all the time (development environment, colleagues, life...). This is true to all professions.

Good strategies? Here are things I do:

• Timebox working on the issue. Meaning only allocate a certain amount of time to try and fix something before escalating it.
• If something is outside your expertise, get an expert. Inform your management of this.

Answer 2

The obvious answer would be to delegate such problems that are not covered by your expertise, especially if these issues are not 'officially' your responsibility.

Assuming the above is not possible, take a look at "Evidence Based Scheduling". I have been in a situation where I was constantly disrupted by external factors (email, phone, support, other developers etc) when trying to code, so I used this method to demonstrate to my superiors how much longer tasks were taking me to complete due to the working environment. The answer was of course far longer than they should have been. This was useful in that it was quickly realised strict deadlines were unrealistic for our particular working environment and that disruptions need to be minimised with urgency. This resulted in more realistic deadlines using the Evidence Based Scheduling approach which helped a great deal in reducing the frustration and/or pressure that comes hand in hand with deadlines.

This may not give you the silver bullet you seek to stop all disruptions, but may be easier than trying to convince your employer to hire more staff.