Developement Anti-patterns

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.

Working or Done

Last night I woke up in the middle of the night, worried about a specific problem in our model layer that I was sure was going to cause problems if it wasn’t resolved. I tossed and turned until about 2:30 when I got out of bed and went downstairs and fired up the laptop.


I started with a code review of some related model classes, and found…
… a small mess that I hadn’t anticipated.

So we had a working model class, with no behavioral problems observable in the application. Sounds OK. Then I looked at the class… WOW – what a mess. Internally, it had a crap ton of spaghetti in private methods, and it implemented a serialization interface that should have been in a different class, and it had knowledge of other classes that should have been encapsulated, etc. There were no appropriate tests written. A mess.Continue Reading

Normalized Perspectives

As software professionals, our beliefs about what qualifies as “best practices” often depends on our experience and our expertise. This is one of the reasons that it is so very difficult to run the self-organizing software teams, frequently described in agile literature. The fact is, teams cannot be self-organizing, until the members share mental maps of both problem and solution domains. Until these maps are truly shared by the team, an external organizing force is required to ensure consistency and solidarity within different aspects of the solution.

I want to share some experience from a recent project, where I have been this “external organizing force”, and how I have observed these varying perspectives come into play, and the impact that they have had. My hope is that some among you will be able to learn from my experience, and be more prepared when you face similar challenges.Continue Reading

Helping the Team

Perhaps you have experienced the struggles of on-boarding new developers into an already large team in the middle of a project. Everybody who comes wants to have a say in how things are done, no matter how late in the process they get involved. Here is a litany of the types of commentary that I hear in this situation:


  • On my last project we used <insert product, pattern, or practice> and it worked great. We should certainly use that here.
  • We don’t need <insert pattern, product, or practice> its too <insert adjective>.
  • Why don’t you just <insert suggestion>.
  • The code-base is in a bad state because <cite example>.

Each of these commentaries were delivered, without necessarily an understanding of the choices that were made by the team to get to this point, nor with a full understanding of the work remaining. I sincerely believe that each developer made the comments in a spirit of trying to help the team. I also believe that each of these comments reflects the developer trying to construct a “familiar” environment where he knows how to deliver value.

Here are the problems with this:


  • Commentary rarely reflects a problem statement before offering a solution.
  • Commentary rarely exposes the cost (in effort and risk) of adopting the solution.
  • Commentator may or may not have the experience or skill to lead the team through the adoption of the solution.
  • Commentator may or may not have thought through the solution to the ultimate conclusion – to determine whether it is feasible, valuable, or reasonable within the context of the project.

I attribute these commentaries to each developer’s on-boarding process, and their process of “mourning” the familiarity of their last engagement, while also trying to understand the current environment.Continue Reading

Fixed Feature Bids

I have worked with a lot of teams made up primarily of contract developers. Not teams from consulting firms, but teams of “assorted” contractors from assorted staff augmentation firms.


Folks that have been doing “short term” staff aug work for a while – (by my definition not longer than a year) – have an hourly mindset. That is, they get paid by the hour. They know that they are the last to show and the first to go – meaning they are only hired when needed, and are rolled off as soon as the work is done. They sometimes have slack periods between gigs, and are almost always willing to bill overtime while they are engaged.Continue Reading

Stretch Role

Hiring has some words that we use to describe what we are looking for:

1) Been There, Done That – you want someone who can do this job with their eyes closed.
2) New Blood – you want someone who will never say, “that is not the way we do it here”.
3) Fresh Meat – you want someone who isn’t already burned out.
4) Youthful Optimism – you want someone who will not stop trying when things get ugly.
5) Hands – you want someone who cranks out work.
6) Brains – you want someone who can show us how to do it better.
7) Potential – you want someone who can become a star.

Hiring is difficult, because you don’t always know what you are getting. But it helps to know what you want. I like these words, because they informally signal what that I am seeking.


Continue Reading