Article summary
The KISS principle is has been highly touted in software design and development for years and stressed in the realm of Agile software development. Most developers desire a simplistic code base and put some thought into it while designing and implementing code… to an extent.
Under the pressures of real development cycles and needing to deliver under frequently too-short timelines, simplicity sometimes is placed on the back burner and becomes technical debt that frequently comes back to bite us. And of course at the least desired times.
More Code Has More Bugs
Proving that bugs do not exist is an impossible task. It has long been preached that complexity leads to bugs, which any real developer has no doubt experienced. Even when we try to be extremely careful, automate tests for our code, and gain experience, we all still create bugs. How can we stop it?
In reality, we can’t eliminate bugs from being introduced. The ratio of bugs to lines of code is usually fairly stable and never goes to zero, even with countermeasures in place. Your best bet is to write less code to tackle your problems… but clever code is usually not more simple and is harder to understand in many cases.
Evaluate Simplicity Continuously
Especially during crunch times, we patch code to fix issues. The level of stress we are under as developers to get something fixed usually works against our desires for simplicity and fixing root causes of unnecessary complexity. Many times individual developers, whole teams, and management will push against refactoring out complexity and investigative efforts. Nevertheless, teams usually end up learning too late that they should have taken the extra couple of hours to make things right up front and pay much more to simplification and code review along the way.
Sanity Rules
When code is overly complex, it is hard to change and understand. A single individual rarely creates a large codebase on their own, developers move on to other jobs, and others take over maintenance. Most of us have also experienced the horror of coming back to a large codebase that was set aside for years, and finding that our own code makes us want to puke.
Automated tests are extremely valuable for regression testing, but are even more powerful for refactoring. Having an extensive test suite in place—with unit, integration, and system-level tests—gives us the freedom and assurance that refactoring of code keeps stability intact, and also lets us sleep at night. Refactoring without tests is a risky endeavor, and likely doomed to fail in most cases, eating away more at our sanity (or lack thereof).
Your sanity is priceless, not only to you, but your peers and customers. Sanity provides the basis for creativity by allowing us to no waste useless cycles worrying about what we have already done, and it breeds confidence. Pay down on your sanity via simplification and sustainable practices. You will not regret the investment!