>Even in my role, I can justify a rewrite by identifying the savings in support, maintenance, and infrastructure, and balance.... It's not all that weird for a

>Even in my role, I can justify a rewrite by identifying the savings in support, maintenance, and infrastructure, and balance.... It's not all that weird for a startup CTO / technical cofounder to say, because in those companies velocity is king, queen and the jack of diamonds; rewriting code is a waste because you're only worried about the next milestone, which is no more than six to nine months out. Mature orgs operate at a different cadence, where your analysis is spot on. (Unfortunately, it often doesn't hold for them either; I've had contracts where I ended up scoping in IT project valuation methodologies so CTOs and/or IT managers could learn how to translate savings into defensible balance-sheet numbers, since the business would only accept "real" savings or revenue enhancement as justification.)