🧩 Why things fall apart at the end

As discussed in the previous two posts, things often go haywire near the end of a project cycle, right before the BIG Release. Why is this? Things seem to go so well at the beginning of the project. While it is impossible to detail every reason this happens, a few are listed below.

Technical debt occurs when problems are half-solved. Things appear to work, but edge cases and inadequate testing lurk beneath the surface. As time progresses, the system becomes more fragile, and significant amounts of time go toward fighting bugs and unplanned problems.

Scope creep is a common phenomenon where features continually accumulate throughout the project. Some of this is natural if it's based on user feedback and learning while implementing. However, there is an unnatural scope creep rooted in engineering whims, just-in-case thinking, and a developer's natural propensity toward complexity. Just because something can be done does not mean it should be.

Integration issues occur when one piece of work combines with another. This is often when new edge cases surface.

Not correctly anticipating user needs is another problem. A team may build something thinking the requirements are understood, but it is not until people start using it that the real needs emerge.

Lastly, there are unknowns that simply cannot be anticipated. Complex systems are just that — impossible to completely understand. People involved at every level are fallible and unpredictable. A large amount of uncertainty simply cannot be known or predicted up front.

The simplest way to address all of these issues is to move the end closer to the beginning — Release First.