The following article is a response to the blog post “Conservatism has no place in project management” by s0952140.
In this post, the author laments that project managers frequently ignore the value of upgrading to a new language, framework or tool. Their central assertion is that it is almost always preferable to throw out old code in favour of a new pattern, framework or language:
“…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”
Their reasoning stems from the belief that once a project reaches a certain age, it will reach an unwieldy complexity , at which point you have only two options: Work fruitlessly on improving old code or throw it all out and start fresh. The author believes this is an easy decision:
“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.”
Dealing with technical debt is important, but the author puts forward a radically simplified view of the situation in most large scale, long term software projects. I can think of three reasons why “Conservatism” in project management is valuable.
- Working with new languages and frameworks comes with considerable risk
- The old software actually works and has been strengthened by years of development
- Developers are often biased towards using new technologies even when that technology may offer little benefit to the project
Just to clarify, the author’s definition of “Conservatism” is wide ranging and is defined not only as a bias against throwing out old code in favour of using new languages, patterns and frameworks, but also as a bias against using new tools. I actually agree with the author on the point about tools. Setting up a bug tracking tool or version control for a project takes hours at most, and the benefits of doing so are so enormous that any manager arguing against them is a fool.
For the other aspects however, I believe a small amount of “Conservatism” may have its place.
Dangers of working on the bleeding edge
Using a brand new framework or language for your project undoubtedly comes with advantages: They allow you to take advantage of exotic paradigms or useful features not present in old frameworks. However, adopting a new technology also comes with significant risks.
Firstly, new technologies often have less libraries and tools. Here’s an experiment : Go to Google and type “J” followed by any verb. Chances are that one of the top results is a Java library. If you decide to scrap your Java system in order to leverage the power of the Julia language, you may find that the benefits of the language’s power are offset by the lack of libraries and developers.
Secondly, newer technology is more likely to have bugs and be subject to change. Developers often forget that many new technologies they are excited about are still in their experimental stages, and the framework implementation may be rapidly morphing during the life cycle of your main product. If one of those changes introduces a bug, you may find yourself spending more time fixing the framework than working on your own product. Remember, even popular and stable new frameworks like NodeJS are still technically in beta (version 0.10.26) .
Old software *works* and has a wealth of knowledge
Throwing out messy code is not as costless an option as the author suggests. At every point in the lifetime of a product, the developers will have learned more about the best way to implement such a product. Surely, the author reasons, if we were to throw out all the current complex old code and start again, we would build a far cleaner, maintainable, and robust system.
This line of reasoning is flawed because it assumes that the developers can remember all the lessons learned during the entire life of the product. For any sufficiently large system, it is definitely not the case that you can keep all of the implementation details in your head at once. However, one thing that can remember all these lessons is the code base itself. Much of the code that looks like a “mess” in a long lasting piece of software is actually code that acts as a workaround for browser compatibility issues, guards against a particularly subversive bug, or deals with a specific corner case for some users.
Often, the more likely scenario when starting a code base from scratch is that you will waste time making all the same mistakes again. Sometimes throwing out old code is the correct course of action, but the author’s assertion that it is always the correct action is misleading.
Inappropriate lust for new technology
Programmers are often so excited by the prospect of using a new and interesting new technology that they fail to consider whether adopting that new technology would have any tangible benefit to developing their business’ product. This was exemplified for me by a light-hearted conversation I overheard during my time interning at Amazon:
Programmer A: “<Complaining about an old perl web system> Look at this code – Its a complete mess! We should switch to NodeJS. It’s way more maintainable AND it scales better”
Programmer B :”We’ve have been adding features to this code base no problem, and this system has already scaled to millions of users. What are you talking about?”
Programmer A: “Look – I just really want to use Node <laughs>”
The point here is that a programmer’s motivations for adopting a new technology may not line up with the needs of a project. While increasing programmer morale definitely has some tangible benefits, sometimes having a “Convservative” project manager to consider the business impact of such a decision (e.g Will changing to this new technology save us money? Will the effort to make a change cost take time away from other tasks?), is of value.
Conclusion
Managing technical debt and adopting new tools and technologies undoubtedly has value, and the author of the original article is right to criticise project managers who may undervalue it. However, the first line of their article is telling: They admit that there may be some cases in which “Conservatism” has a place, but only “Very Rarely”.
Hopefully this article has convinced you that there are several reasons to apply a little “Conservatism” in project management, and that these reasons may be more prevalent in long term, large scale software than the author believes.