Flexibility may be good when doing yoga, but it is bad in code. Pliant code can adapt to most any eventuality. However, pliancy infers complexity, and complexity is never a friend to stable bug-free code that is also maintainable. The best path to robust and stable code is straightforwardness. Your code should do a few things well and not a hundred things poorly. This requires prioritizing what is important to your customer and the project. This is different than prioritizing features, as described in the previous section. This prioritizing on customer goals, considering all options in your code, is of little importance if many of those options are not priority. In that circumstance, the practical result is to expand the code base. Of course, that extra code must now be debugged, tested, and maintained on an ongoing basis. Your customer is probably content with less flexibility and more stable code key features.
Commercial programming should not be approached as a math question from a school exam. My calculus professor graded a 95 percent correct answer as entirely incorrect. It was an all-or-nothing scenario. I had to invest the time and research for the 100 percent correct answer—regardless of how long that process took. That is okay in an academic environment, which is more ivory tower. Plus, as an undergraduate in college, my time is free. College professors did not mind wasting my time and frequently did so. However, commercial programming is more pragmatic. An 80 percent solution that solves 99 percent of the problem is acceptable—especially when, for that extra 1 percent of flexibility, you add measurably more complexity, reduce maintainability, and needlessly extend the development process.
Simple code is easier to debug. That probably sounds obvious but is often forgotten. The greatest challenge to simple code is reining in flexibility. The added flexibility is essentially noise that distracts the developer from focusing on the core functionality.
