OK, I lied. It has. Very rarely. I will get to that.
Too many times I have found myself talking to a project manager, and trying to convince them to use a certain design or architectural pattern, a framework, a language, or in general a tool for their task at hand, and being sent away with the reason “we already used these things in the past, and we don’t have the time to stop and learn new stuff”.
Project managers (or in worst case: their bosses) often over estimate the cost of learning new technologies and underestimate the benefit of that.
“We have this internal ticketing system developed by interns throughout the years. It has been written in PHP, using no framework, 3 people worked on it so far, it has around 10k LOC of spaghetti code. Version control? We send it around in zips to the developers. Anyway, could you extend functionality, and get rid of a few dozen bugs we have?” Not exactly “large scale”, but as an example it shall serve us well.
First of all, ticketing systems exist. Your ticketing system is no different from the thousands of others. Use one. If, for some magical reason (unicorns) you cannot, or simply you would enjoy having your own, and have the time and capacity to implement it, fair enough. But why wouldn’t you spend a man-week to research existing ones? But let’s suppose you did, and, since you want unicorns to be integral part of your ticketing system, you decided to write your own. Or, back in the day when it all started, it was just a side project, that has grown into a usable thing. So now you have it.
And you want to keep it. And you waste a lot of time on it. You still have two choices: 1) keep the cancerous spaghetti code, or 2) redesign it, invest that man-week into setting up a new project, with the right tools, right patterns, right version control etc.
Chuck your old code. If you had wrote some ground breaking algorithms and whatnot, you can still take that and insert in your new project. You lose nothing, other than the cancer.
OK, you decided to chuck the old code, set up a new project, and now you use version control, and you have a nice framework, following some patterns, and you have your new features implemented. Half a year goes by. And then comes this new developer and says, “well, it is all kind of good, but you know there is this new database system / language / test framework / whatever, that fits your situation perfectly, and you could save that 20 hours per week maintenance, if you would implement these”. Again you have to make a choice: be conservative, keep what you have, or try the new things.
At many times in all projects these moments will arise. Should I keep to what I am doing or should I try something new. Always try something new. Since you have version control in place (if you don’t, try it!), you can only lose a very well controlled amount of time. You can always say: you have one week to implement this new this new thing. And one month for everyone to get used to it. There. Five weeks. If the new way is rubbish, you lost five weeks. When you decide to be conservative, you are losing an unmeasurable amount of time, your developers might not be working on the most important aspects of the task, and your users might not have the best user experience they could have. If you only lose a minute a day, and your project is long term, continuously developing, you lose infinite amount of time.
Unfortunately you might not have developers who come to you with the new stuff. You then are in the passive conservative mode. You need to force yourself to constantly look for the new stuff. And try it out when you find it. (And why the hell don’t you have developers who come to you with the new stuff?)
So why did I say I lied in title at the beginning?
You might have very good reasons to chose to use Assembler instead of Python in your project. In the choices of tools or patterns you might, in that sense, very well be conservative. What you should never do, is stick with the old, because it works. Don’t be conservative that way.