It is hard to keep up with the number of times I have worked into a phase of “almost complete software.” We often see this as a marker or milestone that tells us a little push is all that is left. However, that is rarely the case. It seems like the end of the implementation phase is a trigger for this lofty status. We all fall for it. Our product implementation is approaching a final milestone and extend that to being almost done. We overlook so many details that are yet to be done. In listing out some of these details, I am hoping that we can all be a little more realistic in our expectations and setting the same.

Testing Almost Complete Software

Testing cycles can be very short and almost ignored. However, that often ends in low-quality software and unhappy customers. A proper testing cycle can be time-consuming and will often churn on a couple of bugs or features. It is rare for e a project to sail through testing without time spent clarifying issues, how to reproduce bugs and requirement reviews. This phase alone can make the almost complete software claim seem laughable.

Deployment Challenges

Things are getting better with modern CI/CD processes and tools like Docker. These tools and processes help us start working on deployment issues sooner in the SDLC process. However, there is no replacement for the final deployment. It is amazing how often simple things like a point release difference in software, a seemingly negligible configuration value, or changing an address or network can bring down software. Even worse, the errors that appear in production and can not be seen in development often take a while to be identified. That also means these can take a lot of time to track down and correct.

Understandably, one would feel close to the end at this point. The gotcha is that putting something on a production server is when the rubber truly hits the road. User Experience becomes a much more critical factor, and you often see load impact for the first time when you hit production. While many of these issues are addressed in future releases, I have also seen products languish amid deployment issues.

Edge Cases

A good set of requirements that are used to measure progress can help with this issue. Nevertheless, it is not uncommon to run into edge cases and unusual situations that only become visible when you get near the end of a project. These can be attributed to going after “low-hanging fruit” early on in testing and implementation. On the other hand, when we consider the 80-20 rule, this makes all kinds of sense. The two ideas are likely closely related. That last fifth of your journey in building software is going to be beyond the bugs that are easy to identify and fix. You are now in the area where significant challenges like “randomly” appearing bugs and race conditions need to be tackled. These alone can convert almost complete software to early steps in a death march.

I apologize, but I have been on a kick thinking about anti-patterns. They are fascinating to me and an essential part of planning for success. If you want to learn more, then you can find more about anti-patterns all over the web. There are some patterns out there as well, but if you at least avoid some of these project planning, estimation, and execution anti-patterns, your odds of success will increase significantly.