Over the years as I've participated in (and led) software projects, I've come to a conclusion about which archetype is the most damaging member of your staff. It is what we like to call the "Hero Coder". The Hero Coder is that individual (or team) that frequently expends huge amounts of energy, often in the 11th hour, to overcome the shortcomings in process, scheduling, or requirements that put the project success at severe risk.
Oftentimes, the non-technical executives of the business LOVE the hero coder. Despite all the challenges that have been placed in the way, the hero coder jumps in at the last minute and yells "I CAN DO IT!" before embarking on a caffeine supported massive overtime binge. What the business often doesn't realize is the exceptional amount of technical debt that is created during this process. Over time, the hero coder(s) go to bat again and again, and the clarity of the system degrades to the point where it becomes the big ball of mud. As wikipedia states (emphasis mine):
A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.Oftentimes an environment led by a hero coder is one where people are too busy bailing water to patch the leak in the boat. Over time seemingly simple enhancements start to take longer and longer, small changes ripple through the system causing errors in what appear to be unrelated sections. The system becomes nearly impossible to test. Because documentation is neglected in 11th hour scenarios oftentimes the only way to understand what a function is supposed to do is to trace the code. Ultimately, most rational developers at this point are afraid to touch it for fear of what else may break.
So at the end of the day, the damage to the business drags on over the years. It's not just the technical damage that we should be concerned about either, it's the culture damage. The hero coder has created a situation where the expectations of management are that proper planning and execution really aren't all that important, because at the end of the day the feature will ship. The hero coder will make it so, come hell or high water. Any future developers who come into the environment will face fierce resistance to attempting to bring some order and sanity to the "process", because the stakeholders have been trained to believe it isn't necessary.
Unfortunately it tends to take a series of absolute train wrecks of projects before management starts to realize the gravity of the situation. By then, unfortunately, it is likely their shop has been getting a bad reputation in the area due to high turnover among otherwise competent staff.
In a future blog post, I'll go into some tips on agile estimation practices and how you can build a culture that sets reasonable expectations for creating quality code.