The Path of Least Resistance

While fighting with monsters of legacy code, I have kept thinking of all the possible reasons why developers would end up building such a man-made hell. My capacity to analyze the situation and figure out possible causes is limited to the knowledge of the external forces that these developers where exposed to. For what was happening inside of them, I am limited to build analogies after looking at my own battles and shortcomings.

I have been trying to distill a unique question. Here it is: why would a developer choose to the walk the path of least resistance?

Though skill, experience and professional standards are factors at play, I do not think they can explain the whole picture. Deadline pressure certainly encourage to cut corners and follow the easiest and dirtiest path. But the crux of the problem is not there. It is in the resistance.

What is this resistance anyway? It is multiform and hard to characterize. Any developer surely has felt at least once the slight despair it entails: you want to progress and get blocked by a wall of resistance that is not insurmountable but would incur a great cost in term of work disturbance.

Here are a few example of the outcome produced by such a resistance:

• Teams entrenched behind layers of management feel encouraged not to wait for the others to do something that they need and end-up building sub-optimal solutions with what they have now.
• High cost of database changes can drive developers to extremes like the reuse of existing fields, the use of inadequate field types or the storage of serialized objects in BLOBs when a few extra columns would have done the trick.
• Long feedback loops between a code change and the result of testing orient developers towards implementing new features with minimal changes to existing code, which ends up with code duplication, spaghetti plates and design-less applications.
  

Facing resistance, it is very hard for a developer to postpone the completion of his work because, when he is building something, he is driven by the goal to reach and tend to disregard warning signs. This is the same challenge that airplane pilots face when their guts tell them to stay on the ground or to turn back but their focus on reaching the planned destination make them fly into trouble. The only difference is that, oftentimes, these pilots will not survive their decision to ignore warnings, while in software we can move on to a new job and pretend nothing happened.

Taking intelligent decisions while being goal driven is hard. Everybody knows that the path of least resistance is rarely the best one. Alas, we walk it and, I suspect, not by laziness but by renouncement.