If you were really going to make this case, yes, you’re right, you have to take into account the total cost of a new employee, not just his salary (benefits, taxes, new computer, ramp up time). However, if you’re looking at the long term productivity of the team, the initial costs are outweighed by the length of the new employee’s stay, and, again, averaging, or taking a large top number for the cost of a new Tools programmer, will iron out taxes / benefits. I’ll probably do a more involved post at some point.

Those last 2 points, by the way, are issues that I think need to be address on this blog. How to avoid lost work due to data migration, and how to avoid transition downtime. This comes into the larger issue of how to branch off builds, and how to automate a data transition.

There is a tangental point here also. While it is possible to perform rewrites on tools, if those tools are large and critical path, there are many other costs to consider:

1.) Ramp up time on new tool.
2.) Missing functionality in new tool.
3.) New bugs introduced in new tool.
4.) Lost work due to data migration.
5.) Downtime during transition.

This is really just the tip of the iceberg in terms of things you are likely to encounter and need to be prepared for if you or your team undertakes a rewrite of a major tool while in production on your product. While it may be more expensive to do so, refactors should almost always be the correct solution to major tools and tech work being done during development. You need to be able to ensure uptime for your users, and you need them to provide validation on the work being done.

But, I don’t disagree with anything posted on this topic so far.