Comment by runawaybottle
5 years ago
I wish more managers and business stakeholders investigated this more carefully. Team members of this type add a shadow overhead that impacts velocity dramatically. It’s always visible to average competent devs on the team, but can be invisible to managers who don’t investigate as to why only one person is particularly productive on the team. Most people won’t go to their bosses and say ‘so and so writes overly complicated code that’s making my life a living hell’.
In fact, I think a third-party auditor would be a valuable service for dev teams to utilize at least once a year. Totally neutral party that can come in and say ‘We’re pretty sure the codebase is too complex and we noticed the commits came from so and so’. The business value here is you can root-cause velocity issues that can come from decent people who need to be reigned in (not necessarily fired).
I’m literally prepared to pay to have these people objectively assessed.
I would do this auditing job, no joke. A kind of "code-smell" service, that can yield problematic areas, along with a report of engineers that could use additional guidance/training/reigning-in would be super valuable from a manager's perspective. And because it's a neutral party, they can feel good that there's no politics.
One challenging bit about this service would definitely be quantifying improvements. Since the problem is somewhat hidden by nature, you would almost need testimonials from other engineers on the team.
Another way to remove finger-pointing is to identify features that should be reasonably easy to implement, but for whatever reason don’t get done in time, or worse, don’t get done well (end results being bad).
If a team was tasked to make a simple landing page for example, and it was oddly hard or time consuming for an average team member, it would be good to dig into why. If the answer is ‘you should see the boilerplate involved, or the deploy process ...’, then you can make a neutral analysis as to the cause.
Testimonials aren't a bad thing though. I think every dev should have their code read and evaluated by at least one other person, although getting as many people as possible to read it would be best. If code legibility to help team members understand, debug, and improve upon the code is essential, the best metric to use for code quality would be their collective feedback on said code.
> Totally neutral party that can come in and say ‘We’re pretty sure the codebase is too complex and we noticed the commits came from so and so’.
This sounds like it'd reduce psychological safety on the team, to have someone without the project context come in and criticize your engineers. The morale decline of such a choice could outweigh the benefits.
It’s a suggestion. Generally, code complexity is created by someone that is actually pretty knowledgeable and competent. A straight confrontation won’t easily neutralize such a person in a discussion. They will know how to defend. If they also have peers they are close with, those friends will also negligently condone it with a simple ‘I don’t see anything wrong with that implementation’.
It’s a tough one, so I don’t even know where to begin other than an independent arbiter. Anyhow, I agree with you that it is a delicate matter from an emotional perspective (even though the underlying can be a reasonably objective matter).