Ask HN: Need help conveying concept of technical debt to CTO
7 comments
Quit your job if you can. The real problem is that you don't trust the CTOs judgement and you're looking for shortcuts to communicate a very simple concept. I'm not a programmer but I got your issue with the project after reading the three paragraphs you posted above.
If you can't turn the above text into an conversation of very short PowerPoint deck you're "shouting at the winds". By the way your lack of respect may not show up now, but as you work on the project and resent it — that will show up over time (and if nothing else make you depressed).
By the way as a point of pride if I can't explain the "business why" of doing something wrong to a programmer then I've failed as a manager. Because if my programmer has any pride in his/her craftsmanship they'll resent me through out the project and self sabotage.
If you can't turn the above text into an conversation of very short PowerPoint deck you're "shouting at the winds". By the way your lack of respect may not show up now, but as you work on the project and resent it — that will show up over time (and if nothing else make you depressed).
By the way as a point of pride if I can't explain the "business why" of doing something wrong to a programmer then I've failed as a manager. Because if my programmer has any pride in his/her craftsmanship they'll resent me through out the project and self sabotage.
"legacy application in the primary healthcare domain" <-- there are specific reasons why it is preferred to keep with the legacy platform. A lot of effort has been spent to make the system compliant with existing regulations. And switching to a new technology platform isn't a willy-nilly decision.
Ask the CTO about the regulatory and other aspects of the platform. For all we know, he may believe that more time will be spent vetting a new platform than would be spent augmenting an existing platform.
"He's aware that the existing platform has a number of problems" <-- in response to another poster, the CTO is aware of the level of garbage. When you work as a manager on a system like in health care, you have to worry first and foremost about the business.
Ask the CTO about the regulatory and other aspects of the platform. For all we know, he may believe that more time will be spent vetting a new platform than would be spent augmenting an existing platform.
"He's aware that the existing platform has a number of problems" <-- in response to another poster, the CTO is aware of the level of garbage. When you work as a manager on a system like in health care, you have to worry first and foremost about the business.
There is no regulatory framework for health IT systems in my country analogous to HIPPA in the US, nor is the system standards compliant in any way. We have some national health IT standards but we've not invested any effort to make our platform compliant.
Do you have any estimate as to how long it would take to rebuild the platform and shake down the bugs (to the extent that the existing platform functions)? I ask because, if you try to look at it from the other side, it may actually take much longer to rebuild than to patch.
If that time is short, maybe you should try to do it on your downtime :)
If that time is short, maybe you should try to do it on your downtime :)
It would take a long time to rebuild, certainly over a year. I'm not even certain how we could approach refactoring the existing system without unit tests - classic asp is very primitive.
I'm aware that rewriting systems is a big business risk, but I think we have reached a point where maintaining and developing new services on classic asp is a greater risk to the viability of the company.
I'm aware that rewriting systems is a big business risk, but I think we have reached a point where maintaining and developing new services on classic asp is a greater risk to the viability of the company.
"It would take a long time to rebuild, certainly over a year. " <-- is there any way to make incremental changes to a new platform? By that I mean breaking down the transition process into small steps that can be completed one man-week at a time? If not, how well-staffed is your firm? Is it sufficiently well-staffed that some people could dedicate their time to migrating the entire platform?
I'd talk to the CEO instead. While there might be some part of the larger picture you're not seeing, a CTO that doesn't understand or care about the level of garbage in the system isn't doing their job.
I was hired over a year ago with the explicit purpose of helping the company transition to a new platform (I've been advocating something on the JVM, probably Scala and the use of *MQ to help decouple the system). Upon starting however I was immediately seconded to a new development project on the legacy system instead.
The business is now embarking on the development of a new service, which the CTO is intent on building upon the existing platform. He's aware that the existing platform has a number of problems, but due to time constraints he doesn't foresee us having the resource to develop against a contemporary platform. I've tried to convey that doing this will further incur technical debt and even further decrease the agility of the company. I personally feel like this decision is going to hurt the long term viability of the company, but I don't think I have adequately conveyed this. The existing system continues to function, but only through the titanic efforts of our development team, and I can't help feel that because it is functioning there must be some perception that it is not broken.