3 ms·

This sounds like micromanagement, even from a VP of engineering. The CTO should be setting long term vision and roadmaps, VP checking things are progressing & h

This sounds like micromanagement, even from a VP of engineering. The CTO should be setting long term vision and roadmaps, VP checking things are progressing & handling the majority of the business side (hire/fire, sexual harassment + behavioural issue), then directors down deciding how to do things. > Sometime down the road legacy applications become expensive to manage, > but rewrites almost always deliver zero value to the customer. What a weird thing for a CTO to say. Even in my role, I can justify a rewrite by identifying the savings in support, maintenance, and infrastructure, and balance that against the time for the project & make a call that in 6/12/X months, we will have recovered the cost of the rewrite & be saving the company month money (which then can be used to develop more user-facing features, improve performance, etc.)

HillRat 10y ago
>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.)