What are your strategies for having productive dialog about less visible technical issues as a project unfolds?
For further actions, you may consider blocking this person and/or reporting abuse
What are your strategies for having productive dialog about less visible technical issues as a project unfolds?
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (16)
Is there any metric improved solving this issue? This is the right time to show it!
IMO if it's a purely technical issue always a metric will be improved.
And, as you said, they are less visible, but that doesn't make them invisible, so always there is some point in every technical issue that can be shown to the management/client as a real thing they need to be aware of.
I always try to take that to the light and give it the right importance during the meetings.
I told them that in order to add more features (thats what they want) we need to improve the code quality significantly otherwise it will be a complete mess. They understood right away and I invested many hours actually improving the codebase.
I told them that, they didn't listen. Later I am blamed because I spent to much time refactoring things and not adding new features everyday.
(Some people are not smart enough)
It greatly depends on the individual/company. I have a small compilation of issues to mention if I need to just throw out to seem like it's a lot, but there's varying amount of problems that really depends on the project. It greatly varies on short/long-term, relevance, impact and visibility.
Technical:
Quality overall impacts on all of those issues, not only the frequency but the amount of time to fix them. It overall makes it harder to work on a project, resulting in less value delivered from the same investment (time/money/effort/people/whoever you "measure").
Organizational:
I usually use the following analogy for crippling technical debt (that I actively avoid to create myself, but humans be humans):
Do you want me to keep working with my hands tied or are you willing to give me a little bit of time to untie it?
I usually try to not keep my current product/project/environment get too fucked up, but sometimes we inherit products/projects/environments that's too much mess. I either make it clear that I need to refactor it or consider refusing the job.
Make an emphasis that code quality directly affects the time it takes to add new features and modify existing features. The risk of regression also continues to grow in the opposite direction of code quality which means more time spent fixing bugs each iteration.
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.
That’s a good question, and I’m sure it goes into the communication of the original question. 😋
This is a though one. Usually the only / best shot i have on this is...
Linking it to long term delivery timeline (useful for continuous long running projects)
Linking it to perceivable user experience (eg, api being slow affects site load speeds)
Generally though as many clients tends to view IT as a "cost center" as oppose to a "tech asset". I find that linking it to something that affects their business bottom line is the best way to get across the "cost center" barrier.
I usually point out that the accumulated technical debt associated with poor quality code will impact the length of time it will take to develop new features. It will also increase the amount of time spent on bug fixing.
Not only do I point out this problem and how it relates to the delivery of features, but I also point out how it leads to developer frustration. Developers who are forced to navigate "sub-optimal" code will be frustrated at the increased difficulty related to working with the code. Management usually understands that unhappy developers means the potential for an increase in employee turnover as well as potentially more difficulty acquiring new developer talent.
Rarely talk about it.
However I heard a colleague say to a client once: "You can't drive a car and repair it at the same time" to the endless requests of new features...
I thought that was clever :D
Some comments may only be visible to logged-in visitors. Sign in to view all comments.