

Ask HN: Need help conveying concept of technical debt to CTO - squidsoup

My company maintains a legacy application in the primary healthcare domain written in classic asp. The app has all of the problems that you would expect with anything written in classic asp - no separation of concerns, innumerable redundancies, no tests of any kind, brittle business logic etc. Working with the system is unnecessarily difficult and can make what should be easy tasks very laborious. We are frequently turning away new contracts simply because we don't have the resource to serve new customers on the platform.<p>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.<p>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.
======
michaelpinto
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.

------
veyron
"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.

~~~
squidsoup
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.

~~~
veyron
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 :)

~~~
squidsoup
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.

~~~
veyron
"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?

------
Animus7
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.

