This is golden advice and for me understanding this is one of the differentiators between junior and senior developers. All too often developers seem to be ben

This is golden advice and for me understanding this is one of the differentiators between junior and senior developers. All too often developers seem to be bent on the idea that they have been hired to write code and so the solution to any problem they are asked to solve must be more code. The truth (or at least the way I understand it) is that writing code should be something that happens when you have explored every other option possible. Even if it is easy to write, code is expensive to maintain later on and the costs do not add linearly. The larger the project the more it costs to maintain anything. Simple operations become huge projects. The best bet, in my mind, is to try to have as little code as possible by treating the code as a liability and trying to curb the amount of it from the start. Even if you need to add code to add a functionality, it is frequently possible to shift it from somewhere else. Refactoring as you add functionality is a good way to curb the size of the code base. Another way I have noticed that seems to be frequently overlooked is to have the object model as close to your real problem. Any inconsistencies between real life and software object model seems to result in heaps of code in multiple components to deal with various exceptions, translations, mappings, etc. and this seems to grow exponentially with time. Sometimes there is no better way than just do it right from the start. I work for a large bank on a system that deals with risk calculation. It seems every part of organization has a slightly different understanding of what a trade is or definitions of its properties. The net result is that, in my estimation, there is about 3 orders of magnitude more code that would be necessary if there was single shared definition of all those properties.