Bear with me while I dabble in religion for a second…
When God created everything, God saw what God had made and said it was very good. When a developer looks at a few lines of code they think, “This could be done better!” The developer then jumps down the rabbit hole of refactoring.
If God could declare the earth good with all known issues, the engineer should be able to do the same. Even if the functioning code is less than SOLID. For heaven’s sake, let it go make money!
You may have read Code Complete. If not, I highly recommend it. When talking about code design, the author Steve McConnel writes:
In an ideal world, every system could run instantly, consume zero storage space, use zero network bandwidth, never contain any errors, and cost nothing to build. In the real world, a key part of the designer’s job is to weigh competing design characteristics and strike a balance among those characteristics. If a fast response rate is more important
than minimizing development time, a designer will choose one design. If minimizing development time is more important, a good designer will craft a different design.
Like every paragraph in the book, there is a lot to unpack. One take-away for me is that minimizing development time is a design choice!
Before we write code, we can consider our timeline and then approach the code with that lens. When we are done, we can look at what we wrote, unit tested and released and say that it is very good. Code is good because it is finished, not because it is perfect.
One technique that I have found valuable is Timeboxing. Give a task a specific amount of time for completion to stay out of the deep void developers often find themselves in. Use this technique whenever you consider refactoring efforts, production support investigations, and looking into a new technology or pattern.
Just remember…God gave God’s-self six days for everything.
That’s not even a sprint!