Increasing, Not Diminishing: Investigating Returns of Highly Maintainable Code

Re:Increasing, Not Diminishing: Investigating Returns of Hig... by pylua on Monday March 18, 2024 @08:42PM (#39751791)

Code quality is very subjective. Assuming you eliminate the extreme cases of poor code and great code, most people being average, the best thing to do is keep a talented team together as long as possible. The team will accrue knowledge slowly at first but will produce dividends later on as they will have the best knowledge of the system.

Excluding extremely poor situations it is domain knowledge that drives defects, not the code.

[ Parent | on HN ]

Re:Increasing, Not Diminishing: Investigating Returns of Hig... by taxikabs on Tuesday March 19, 2024 @09:53AM (#39755754)

That sounds ideal, but hard to control ultimately. Pay and opportunities for growth are typically going to be constrained at most places long term.

It seems like it's worth identifying weak spots in your codebases where higher complexity is lying, you have sole contributors on your team, or buggy areas. Armed with the information, you can plan ahead for them. Would refactoring into a different design better manage the complexity? Can we get more team members involved in changes to parts of a system we don't have familiarity with, for redundancy? Why are we fielding so many bugs in this functionality and how do we mitigate it?

[ Parent | on HN ]