Fail

A certain way to ensure failure on any software development project is to manipulate a team members’ view of what defines success for the feature/application. Any time new features are getting implemented (per requirement) ask the following questions:

• Does this provide reusability in other areas of the application?
• Is it horizontally scalable?
• Is it interfaced in case you need to use a different implementation?
• Is the code portable on different platforms with no changes?

If the answer is no to any of the above questions, then there hasn’t been enough planning for the feature. Don’t worry about conserving time and delivering sooner. Focus on building for all possible scenarios even if requirements don’t call for it (you never know)!

Resolution

Have you ever been involved with a team member who felt every piece of code in the system had to be extensible, interchangeable, self healing, or scalable? It seemed that requirements that were not even the concern of the project sponsors were always in this particular team member’s mind while writing or critiquing code.

As in any construction project, there must be a vision or definition of what is to be built.

If the “box” is the boundary of constraints and conditions, then the trick is to find the box… Don’t think outside the box—find the box.

- Andy Hung and Dave Thomas in Code Complete: A Practical Handbook of Software Construction

Treat the development of software like evolution (if you believe in it). Humans didn’t develop overnight. Millions of iterations took place and feedback (aka survival of the fittest) was provided to determine the best solution.

* DISCLAIMER * Please note that Friday Failure is meant to provide humor at what can go wrong when poor development practices are used. I’ve likely made this mistake plenty of times in my career.