I'm a software engineer working as a full-stack developer using JavaScript, Node.js, and React. I write about my experiences in tech, tutorials, and share helpful hints.
This has been a huge challenge with long-term clients, I'm interested to see some other answers on this one.
Usually, they will want to do a redesign of an area of their site and add new features to improve it along with that. The problem is that it is a legacy system and every feature is a "must-have", so compromises cannot be made. The projects themselves sound reasonable if they were standalone websites. But because the data, back-end, and front-end are coupled with the entire site and a huge mess, we have to quote projects like that very high.
Because of the high cost, it scares them off and the secondary quote requested is for "just the redesign." It usually ends up with just putting fresh paint on top of the old stuff. It is a frustrating development experience because we have old files with inline server-side code + HTML/CSS/JS sprinkled throughout. Trying to determine what code is still relevant and how to bring it up to a maintainable standard is still a huge undertaking and can even increase the technical debt in some cases. But it is less than setting up a good foundation, porting over the existing functionality, adding the new design, and adding the new features.
It is tricky because our bosses want to maintain the relationship with the client. When improvements like technical debt recovery, security, source control, deployments, etc. are recommended, the question is always "why aren't you already doing this?" If we build in time for improvements into project quotes, they do not want to do them.
There also is not a way that I can think of to measure the cost of technical debt. There is no easy way to say if more time is spent making things better now, it will return $X to you in future projects. We can only vaguely state "less time in the future." Both management and clients would just be taking the developers word for it, which I can see why it would be shrugged off.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This has been a huge challenge with long-term clients, I'm interested to see some other answers on this one.
Usually, they will want to do a redesign of an area of their site and add new features to improve it along with that. The problem is that it is a legacy system and every feature is a "must-have", so compromises cannot be made. The projects themselves sound reasonable if they were standalone websites. But because the data, back-end, and front-end are coupled with the entire site and a huge mess, we have to quote projects like that very high.
Because of the high cost, it scares them off and the secondary quote requested is for "just the redesign." It usually ends up with just putting fresh paint on top of the old stuff. It is a frustrating development experience because we have old files with inline server-side code + HTML/CSS/JS sprinkled throughout. Trying to determine what code is still relevant and how to bring it up to a maintainable standard is still a huge undertaking and can even increase the technical debt in some cases. But it is less than setting up a good foundation, porting over the existing functionality, adding the new design, and adding the new features.
It is tricky because our bosses want to maintain the relationship with the client. When improvements like technical debt recovery, security, source control, deployments, etc. are recommended, the question is always "why aren't you already doing this?" If we build in time for improvements into project quotes, they do not want to do them.
There also is not a way that I can think of to measure the cost of technical debt. There is no easy way to say if more time is spent making things better now, it will return $X to you in future projects. We can only vaguely state "less time in the future." Both management and clients would just be taking the developers word for it, which I can see why it would be shrugged off.