In an earlier job, I often suffered the typical unexpected attack: a manager or project manager would come to me and my team asking us to fix or deploy something that, by some stroke of magic, had become critical that very day. Perhaps it had been sitting forgotten in a drawer until it suddenly blew up in their hands.
Nothing is worse for a programmer than having to fix a bug or add a new feature under time pressure, especially when it wasn’t planned.
This may sound like an excuse, but when we work under excessive pressure, we start abandoning good practices, good habits, and the discipline of testing as we go. When time is running out, we cut corners without realizing there’s a tremendous cost—and sometimes the results are disastrous. We update things we assume work fine and believe won’t cause problems (without imagining possible side effects), forget the discipline of version control (after all, we’ve been told this is critical), and barely have time to test the whole system, to name just a few examples. In short, when something critical lands on our desk, we forget everything else and focus solely on the problem.
The issue isn’t so much whether we can handle these situations occasionally, but what happens when they become chronic and turn into the usual way of working. In that case, the resulting software will be terrible. This is a recurring subject in The Programmer’s Black Book, so let me remind you that poor-quality code means problems: unmaintainable solutions, greater costs because of the difficulty of introducing changes, solutions that new team members cannot easily take over, and, ultimately, frustrated programmers who spend more time debugging than creating valuable code.
Working under pressure to solve problems we didn’t anticipate is a typical scenario in which the person applying the pressure has no idea about software. They see programmers as people whose work is like connecting wires: either the wires are connected correctly or they aren’t, and that’s all there is to it. Personally, I believe that anyone leading a development team should have deep software knowledge.
Always—and I mean always—when I’ve found myself in this situation, the diagnosis has been the same: poorly planned project management and terrible organization. The problem is that this lack of effective work gets passed on to the development team. Nor can we excuse clients who suddenly discover a critical bug that will shake their organization: if the work has been done properly, this situation shouldn’t happen.
In any case, if we find ourselves in this position and realize that meeting the deadline means leaving loose ends and entering a risky zone, we must notify the managers appropriately. A simple email is enough: tactfully but firmly warn them that there isn’t enough time to test thoroughly or implement the requested changes. This is one way of delegating responsibility.
It’s also a question of attitude: are we here to absorb the poor organization of those higher up the hierarchy? Is that professional? I’ve seen projects fail not because the developers lacked skill or diligence, but because of management problems.
Knowing how to say, “I’m sorry, this can’t be done by tomorrow,” has positive effects worth considering: we honor our work (we aren’t paid merely to work; a professional aims to do a good job, and that’s not the same thing). Also, one or two noes of this kind may make the person causing the problem think twice and try to avoid it in the future—which simply means organizing better.
These situations also reveal a total lack of productivity. When they become chronic, we know what kind of company we work for. When we identify a manager whose way of working is defined by chaos, the remaining option may be to move to another team, department, or company. A professional becomes a professional precisely by doing excellent work; that is their résumé and the way they progress.
As developers who earn our living through the quality of our work, we should take this as a guiding principle: most of our activities must be properly planned. We need a clear roadmap, while setting aside a small percentage of our time for deviations and unexpected events.