We do definitely need to always consider the complexity of software that we create. Even though just for my own use, I have been developing SQL code ( it's all I know how to code any more ) to clean, validate, and reformat a batch of about 1.2 million .CSV rows exported regularly from a pretty poorly designed application with a number of glaring problems, such as program logic based on special characters embedded in the data elements.
It is a pretty complex task that requires use of many of the SQL string functions that operate on a large temporary table. I could have done the process in fewer SQL commands and fewer passes of the table, but chose to go step by step with fewer nested functions with each well documented in comments - so I can remember what it does. I also constructed the temporary table with both the original AND the modified .CSV rows side by side so I could visually debug the process step-by-step as I work on it.
This way I can keep the code fairly understandable, and the code processes the multiple passes of 1.2 million rows in less than two minutes.
This reminds me of the old adage from early IBM days in the 1960's about using the KISS method (Keep It Simple, Stupid).
One of the best days of my IT career was they day I told my boss if the problem was so simple he should go fix it himself.