software development II

You will always regret the hack

Every project gets hairy at some point.  Deadlines start to loom, customer requirements start to tighten, subcontractors and ingredient suppliers are late or flake out entirely.  The team gets stressed and the iron triangle reminds you of its immutable force:

the ol' iron triangle

Adding resources at this point never works.  Even if you have some ninja team of superhuman developers in your back pocket, they won't be able to parachute in at the last minute and do anything right away other than churn the project and introduce more problems.

Slipping the schedule is always tempting.  Reducing features is often what happens.  Sometimes we're smart about it and try to stage them together; reduce the features in the first release, with a schedule for releasing the remainder of the features in the future.

The worst thing that happens is when the decision is made to fight the triangle and keep the same schedule with the same features.  When that happens something else gives--Quality.

In software, when quality slips this usually means that the developers start to introduce hacks.

Magic numbers start to appear instead of declared variables.  Convoluted blocks of nested code get tucked into other functions instead of broken out into separate functions.  Blocks of code get commented out.  Blocks of code go undocumented.  Temporary variable names that make no sense get introduced.  Single purpose design takes over and expandable, scalable features fall by the way-side.  Unit tests and BAT tests go unwritten.

Your software product effectively gets downgraded to proof-of-concept.  When you need to build more later, you're instead spending time refactoring the junk you slapped together.  When users find errors it takes 5x as long to troubleshoot.  At the end of the day, you give up a lot more than you gained and always, always regret it.