There it was... Just sitting there, in all of its beauty. Nothing was wrong with it... Of course, until we contaminated it. It was a zero byte sized, empty file. It was perfect. We mistakenly thought it needed some improvement. So we filled it up with some source code.
It was actually the outside world that really needed the fixing. The idea was to bring in just enough of that (external) complexity into our program. Just enough so that we could straighten it out, a little. When we pull in too much of that chaos then the internal complexity (of our program) rises. If we reach such point then we will often resort to reliance on external tooling to solve our new found problems.
It's like we were trying to help someone out of a ditch and we ended up in there ourselves.
The problem here, in case you haven't noticed, is that we are deploying new tools & processes in attempt to tame our original tools & processes. So we are now effectively trying to solve two problems, at once. We're trying to manage the outside world's problem, internally, within our program's source code. While, on the other hand, we are also trying to manage our own internal issues with external help, as well. It's like we were trying to help someone out of a ditch and we ended up in there ourselves.
Let's take a step back; rewind to the beginning. We should take a look at the so called perfect traits of our blank document -- before we'd ever stepped foot into it. It was: bug free; optimally sized; needed no refactoring; didn't use a slow/bloated framework; memory & runtime footprint was invisible; zero concurrency issues; ideally structured; zero style inconsistencies; composed entirely of the best line of code ever (the unwritten one). It followed every principle (DRY, KISS, YAGNI, POLA) to the letter. We'd better have an extremely good reason to change any of it.
To write softly is to carry a big stick
We should try our best to maintain consistency with the existing (empty) source. Can the problem be solved, at least initially, without adding a line of code? Could we assume that we won't be needing that framework? Can't we stick to a single thread to begin with? Should we just use a stub for accessing the data layer, for now?
The point is that, although we often feel the need to come in swinging, everyone may be a lot better off if we tread lightly. Any change to the internal state of our document should offer a greater and positive impact to the external state that we are aiming to improve. To write softly is to carry a big stick. ☺
Be lean, stay agile, and minimize technical debt.