5

I'm a team lead for a small group of programmers. We share several projects with other teams. Lately the quality of two other teams' code has deteriorated to the point where it is slowing us down and causing maintainability issues. I've raised this diplomatically with a couple of individuals directly, but they become defensive and dismissive. I don't have the clout to go over their heads, and ultimately I need to work with these people so I don't want to annoy them too much.

I'm wondering if there's a process or a forum that can help improve the code for everyone? We already have basic things like well-documented coding standards, tests, linting, code reviews, etc.

But I'm thinking there's more we could do. Maybe a system where developers can anonymously praise or criticise others' code. Or maybe a type of informal meeting where someone can present some problematic code and describe the issues it causes and suggest a refactor. The original author could have the opportunity to defend their work, and then everyone gets to vote on the outcome... if there's a way to do that without being outrageously confrontational.

Has anyone tried something similar, and how did it work out? Any other suggestions? (Apologies for the open-ended questions)

  • Problematic as in has lots of bugs, or poorly designed/thought out? Do the tickets contain enough information and documentation? – Juha Untinen Aug 31 '18 at 14:39
  • Have you listened to the defensive arguments? What did they told you? – Josef Cech Aug 31 '18 at 14:52
  • @JuhaUntinen - poorly thought out, overcomplicated stuff that violates separation of concerns, DRY, and the principle of least surprise. Inappropriate design patterns, inaccurate naming, and lack of attention to security issues. They're all just basic things that shouldn't need to be explicitly requested in the tickets. – manannan Aug 31 '18 at 15:17
  • @Josef the only valid defensive argument was that stuff just needs to get done under time constraints. However I don't accept that because (a) the quality issues persist even when not under a tight deadline, (b) bad habits are bleeding over into more junior team members now, and (c) ultimately the maintainability issues cost us all more time in the long run. – manannan Aug 31 '18 at 15:25
  • @manannan Thanks. Who sets and enforces deadlines then? And is there somebody to protect the team and code against them? I would not discount their answer, you may be actually talking to the wrong people about this problem. – Josef Cech Aug 31 '18 at 17:35
1

If time is the highest priority, then you're not going to get quality. It sounds like you have all the usual standards in place, just no time to actually enforce them.

You don't say if you have a formal change control process.

If someone raises a ticket for a new feature or a bug fix, the ticket needs to identify what needs to be done. Someone gets assigned to do it. But the updated code doesn't get committed to the main build until it's been passed by a change control board (a few more senior members of the project). They don't approve it without the evidence that it's passed static code analysis, peer review and testing. Only once the CCB are happy does the code get committed and the ticket closed.

| improve this answer | |
  • That's a good idea that I hadn't come across. That would be really helpful when someone is about to make changes that can't be reversed, that affect customers and impose limitations on future development. – manannan Sep 1 '18 at 17:26
11

I don't have the clout to go over their heads

You're the team lead, this gives you the clout.

If the problems are with another team, you should raise this with their team lead and discuss the issue of the code quality that's effecting everyone.

Have a meeting with them with a view to increasing quality across the board.

Trying out new processes probably won't work as you've already put coding quality/standard processes in place that clearly aren't working well enough. Adding another one won't improve quality, it'll just add more of a burden to everyone else.

Tackle this as a team of team leads.

| improve this answer | |
  • 1
    One of the other team leads is the worst offender though (we write code too). His stuff is objectively bad; at least 5 other people have commented on it. I always feel more comfortable using a process when trying to impose a consensus on someone. – manannan Aug 31 '18 at 14:28
  • 4
    Then discuss it with the team leads that are producing decent quality code and work together. – user44108 Aug 31 '18 at 14:40

Not the answer you're looking for? Browse other questions tagged .