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
Read next
Exploring the Evolution and Impact of Character AI in Modern Technology
Felix Marvin -
What Would Be The Impact of 28.7 Million Software Developers' Striking In 2024?
Helitha Rupasinghe -
What was your win this week?
Michael Tharrington -
Rethinking Leap Years: Why Your Favorite Programming Language's Approach May Be Flawed
Maxi Contieri -
Top comments (16)
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
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)
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 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.
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.
I use these questions to start the conversation pretty often.
The first one is almost always, "No," and you can ask why they think they can't ship new ideas more frequently (Not faster). Keep probing why we purposefully put gates up to keep things from going out the door.
The second one they won't know the answer to. I work with them to find out what their actual cost of ownership is. For everyone, this is like looking at how much you spend on fast food in a month. I then talk about what makes things cost the way they do and where they can invest in making that ownership cost lower.
The third question is called the innovation ratio and is similar to the second in that it demands we think of our investment in terms of value adding vs non-value adding. Quality keeps the non-value cost low. Invest in lowering that non-value amount.
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.
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.
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.
Hey,
I think this is a perspective comparison with the customer.
Mostly the customer does not know 100% what he wants.
So the customer has only a vague idea and the idea has to grow during the development.
In doing so, projects are made "technical debts".
There comes a new function after another.
If there are too many or large debts, they have to be reduced.
Similar to Boolean algebra, you can shorten it to become more efficient. In the process, mature (conceptually mature) functionalities are considered, analyzed and redesigned.
The easy way is to tell the customer from the beginning that debts are made and these are to be reduced in the course. How much debt you have to pay depends very much on the client's mentality / IT affinity and the project.
I find it difficult to use the word "code quality".
The customer ALWAYS gets the best quality that was possible at the time, even if there are debts.
In fact, all my customers understand this and initially prefer a fast development with certain technical debts that are clearly communicated. This clearly shows the customer that the expansion of a function can then be more expensive. You have to pay for debts...
A big technical dept is if you develop something in a technology just because you have knowledge on it but some other technology fits much better for the Project. This gives speed in the first rounds of a project but this may require a complete new implementation in the future. If no debt is allowed, agile working can not be successful.
If you do not pay these debts, you often can not reach the last "20%". But it can turn out in a project that 80% are enough, you pay for something that you do not need (over Engineered)
Creating awareness always helps in software development.
As long as everyone agrees everything is awesome.
It's a great question, Ben !
And actually I think that it's an issue with some agile methodologies. In principle, we should prioritise tasks based on the added value for the user ... So we basically always postpone code quality.
To me, it's a big challenge in terms of project management !
That’s a good question, and I’m sure it goes into the communication of the original question. 😋
Mostly I'm avoiding that dialog. I try to reserve up to 20% of my time on removing technical debt.
I describe these things as a series of increasing costs:
Some comments may only be visible to logged-in visitors. Sign in to view all comments.