Fear Driven Development – When developers are under time pressure, and are more concerned about their reputation than their code base. They tend to deliver half baked code with all kinds of smells – to get it out the door on time – without thinking of the consequences. When their bad practices are called out by others re-working their work product – they deflect responsibility, blame others, and exhibit all manner of personality defects. The core of it is this:
“Fear turns non-competent learners into incompetent blamers.”
In order to invert this anti-pattern, we need to remove fear of reputational loss. This is necessary for healthy collaboration and learning. This could be accomplished by destroying the reputation publicly no reputation, no fear. This could be destructive, or constructive – but it works fast. This could also be accomplished by exposing a value system that displaces the fear. This is a longer road, and a more positive, happy road – but it requires a tremendous amount of thought and preparation.
Date Driven Development – When developers are incented by schedule alone, you will get all manner of bad behavior. Incomplete features swept under the carpet. Taking technical shortcuts designed to get us into production, but requiring a complete rewrite in 2 releases. Developers in this practice often collaborate well, but never expose to management just what shortcuts or compromises are taken. Often, you are lucky to get through acceptance testing before the software turns into a smoldering heap. The core of this is a management problem:
“Schedule is more important than cost or quality.”
In order to invert this anti-pattern, we need to understand the cost of the date in terms of re-work, and allow the management to make a different decision. They still could choose the date, knowing the cost – but you may actually get to do the re-write – instead of living with the steaming pile for 6 releases of hell.
Documentation Driven Development – When developers are responsible for documentation in a high ceremony, heavy software development life cycle, it often is the completion of documentation that is audited, rather than the code or the content. Developers forget that design is about making good decisions and choices and simply document the arbitrary compromises they made. The core of this anti-pattern is a world view:
“Process is more important than talent.”
In order to invert this, an infusion of talent is required. Talent values talent. Making project managers with limited development skills into team leaders or middle management, or allowing your software development methodology to become infected with regulatory documentation requirements being the two likely initiators of this anti-pattern. Go hire some serious talent, and let them hire some more talent. Listen to those talented developers tell you how you can do good design first, then figure out how to document that design sufficiently to pass an audit.
Die-Hard Driven Development – When developers are isolated and allowed to work “un-supervised” for extended periods of time, without integrating features or concepts together. It is hard to predict the result when you finally take a look at what has been built, but you can bet there will be booby traps, explosions and lots and lots of cursing. Often this is a result of attempting too much parallelism in an attempt to go fast. Sometimes it is experienced when the developers are very familiar with the business domain so they feel entitled to “code ahead” of requirements. The core of this methodology is process dependency inversion:
“We’ll start coding, while you gather requirements, ‘cuz we know what they want anyway.”
The way to invert this is to implement two common agile practices: 1) code swarming – rather than having 1 developer completing an entire feature – pile a bunch of developers on the feature in close collaboration. 2) walking skeleton – if the requirements are still squishy, and development has excess capacity, have them build a thin implementation of some core features, rather than building “final” versions of those features. Using these practices – drives core design concepts and implementation practices through the team together, rather than having each developer follow their own path (yippee ki yay mutha-f…). You get a small number of consistent working features soon, rather than a crap-ton of half baked inconsistent features later.
Demo Driven Development – When the process includes frequent demos to customer, it is customary right before a demo to quick-fix a bunch of defects in a cheap way to appear to have made more progress than you have. While it is somewhat disingenuous, it is hard to resist sweeping a bunch of stuff under the rug to impress your customer. The problem is when your dev’s do that without your knowledge and incur unmeasured technical debt. The essence of this anti-pattern is represented in this statement:
“We’ll keep polishing the turd, while you tell stories to the customer.”
One way to invert this anti-pattern is to implement peer code reviews. Having others review your code solves a number of problems – no programmer likes to look bad in front of an audience, even if it is their cube mate. It also helps good devs socialize better practices and new ideas.
