"We value code that is easy to maintain over code that is easy to write" from Growing object-oriented software guided by tests.

"Quick becomes quicksand" Uncle Bob.
This is the first post in the Series on wise software catchphrases

This is probably one of the most overarching catchphrases in this series, I have often mentioned it to a junior developer while working on a task.

Just think about it for a second: You sit with the task of writing new code for maybe a day or two. After that, you and other people come back to the code again and again.

So often when we develop software we have a deadline or at least a product owner who waits for the task to finish. Completing the task quickly and cut some corners seems like a good way to satisfy everybody, and we can always fix the code later.
Thinking like this is what makes a mess of a code base. History and experience show that getting back to technical debt and fixing it later never (or only rarely) happens.
So if we follow the mantra of cutting corners to deliver quickly we end up with a codebase that has a lot of technical debt. If you do this over a period of time you will move slowly and the product owner will wonder why you are so slow, you used to be so quick.
Believe me, I have worked on code bases that had been developed in the spirit of delivering fast and in the end, it was not fast at all.

As you can see taking it slow will make it quick in the long run.
This particular catchphrase is, as I already mentioned, one that is overarching in this series, and hence the following posts will assume that we strive for code that is easy to maintain over code that is easy to write.