How do you talk about code quality with management/clients?

What are your strategies for having productive dialog about less visible technical issues as a project unfolds?

Comments

[Damien Cosset]

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

[Atanas Atanasov]

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.

[Md Abu Taher]

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)

[Saulo Vargas]

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.

[Robert Cooper]

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.

[Esteban Hernández]

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.

[Ryan Latta]

I use these questions to start the conversation pretty often.

• Are you happy at the rate we are able to release new features to our customers?
• How much does it actually cost for this product exist (Salaries, support, maintenance, infrastructure, development)?
• Say each sprint costs $100. How much of that $100 goes to those new features that help the business and how much do we have to spend keeping things running?

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.

[Rodrigo Nonose]

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:

• Bugs
• Performance issues
• Infrastructure cost
• Feature "throughput"
• Scalability

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:

• Higher turn-over due to overtime, stress and uncertainty
• Creates a culture that incentivizes heroes that saves the day by putting fires (related to broken window theory)
• Reduced knowledge sharing (less readable code and necessity to communicate more)
• Too much focus on technical things since it takes more effort and energy, less focus on delivering a good product/service

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.

[Ryan Smith]

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.

[Eugene Cheah]

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)

  • Long term schedule can be shorter : faster go to market

• Linking it to perceivable user experience (eg, api being slow affects site load speeds)

  • User experience can be better : better revenue??

---

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.

[Ricardo Rivera]

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.