Why Code Takes a Long Time

In this post, which I'll update throughout the year as I'm inspired, I'll try to list all the reasons why projects take longer than expected.  This list will specifically avoid addressing why estimates are incorrect; I consider that to be a separate issue.  Some of it is inspired by the Classic Mistakes Enumerated post I mentioned below.  This list comes from the book Rapid Development, which suggests posting lists like this in tech areas and encouraging everyone to review them frequently to identify problems as quickly as possible.

In addition to posting these publicly, I'll do two things with the information: 1) after each project completes, I'll try to identify which of these (if any) were responsible for slowing it down, and by how much and 2) before each project starts, I'll try to anticipate which of these might slow down the project and try to figure out how to mitigate them, if possible.

• Scope creep.  The project grows beyond its initial spec.
• Over-architecture.  The design was too complicated for the requirements.
• Technical debt.  The project required refactoring legacy code.
• Incomplete or vague spec.  The project was too loosely spec'ed, so time was spent figuring out what to do instead of doing it.
• Performance concerns.  Simple projects can become unexpectedly complicated in the context of a high-traffic, scalable website.
• Personality conflicts.  If a team doesn't work well together, productivity suffers.
• Divergent design.  Hopefully different components of a system integrate well together, or converge.  Sometimes a lack of foresight leads to a system with a bunch of components that don't end up fitting together.
• Inadequate design.  It's easy to be lulled into complacency on simple projects, when in fact they're worthy of a thorough design.
• Unknown technical work.  Whether a project needs research before starting, or involves a third-party API you're not familiar, any unknown variables are often a source of delays.