One of the most frustrating situations in software development is when one side decides to “change the rules.” There have been examples on both sides of the equation that I have seen ultimately derail a project right before completing a project. We even do it to ourselves at times. I hope that listing a few common mistakes will help you identify and avoid them in the future. It may bring world peace a step closer.

The Nickel And Dime

There is nothing I can think of that destroys trust between customers and vendors than either side chipping away at the other. A vendor does this with a steady stream of little change request charges. Instead of working together with clear deliverables and a plan, they get stuck in the weeds. A client does this by trying to get tasks turned into “non-billable” and drags the team into unnecessary detail. The thing about software development is that it is complicated in most situations. There is enough to worry about without nitpicking the details late in the game. Do not read this as the “details” being unimportant. They are critical in completing a project successfully. It is just that those need to be hashed out early on and not when the end is nigh. When you do this, you will avoid a feeling of death by a thousand cuts.

Just A Little More

This particular anti-pattern may be the one I relate to most. There are two conflicting traits many of us see as we approach the end of a project. However, they can combine to spin us off into oblivion. The first trait is what I call the “90% high”. This situation occurs when we “know” we are almost through with a project and have a burst of energy to get across that finish line. Think of it as a runner sprinting that last one hundred yards of a marathon.

The other trait is one we will call “just a little more.” This situation arises when we feel we are close to the end and can squeeze in a few more features or finishing touches. When we have that extra energy to drive to the end and a desire to keep adding a little scope, we can rapidly go off course. It is almost like we do not want to get across that finish line and instead want to stay “in the zone” as long as possible.

Perfection Over Reality

Sometimes completing a project is hindered by quality assurance and testing results. The application is almost complete except there are some bugs to fix. While some bugs must be addressed to provide a useful product, some others do not. For example, I have seen projects wallow in testing cycles as minor things like pixel-perfect displays, wording for labels, and fonts or sizes are “fixed.” These might be issues that impact the usability and correctness of a product. However, that is rarely the case.

These sort of nit-picking details can drag out the testing cycle beyond reason. Keep an option for “known bugs” that can be addressed in a future version. Users may not wait forever while you perfect that current release. Even worse, I have seen situations where wording (copy) is minutely engineered only to find out that it ends up negatively impacting users. Yes, even copy can be over-engineered.

Agile To Infinity

One of the strengths of an Agile approach is that releases should be common and regular. However, that does not stop some groups from dragging out a production release. This situation is similar to the “just a lttle more” pattern. However, in this case, production releases are pushed off for “just one more sprint” instead of tightening things up and pushing it to users. Instead of a litttle item here or there, this pattern becomes a few more features, bug fixes, or performance improvements. Sometimes there has to be a person the team that can make the “fish or cut bait” call and drag the project across the finish line.

These are just a few of the ways to avoid completing a project. You can find anti-patterns all over the web. Nevertheless, I find these to be highly common and often easy to avoid. Of course, it all starts with a plan, and then the team needs to keep working towards that plan. Changing mid-course can turn you right into an anti-pattern.