0

This question already has an answer here:

I had a conversation once with a with a senior development manager. I said that I aimed to produce "good" code, meaning code that is high quality. He said that good code is functional, performant and secure, and "quality" is not even an issue.

His justifications were that what makes good quality code is subjective, and that in their team people tend to specialise in certain areas of the software, so that it is nearly always developer X who maintains class Y. He added that if that developer leaves or changes responsibilities then the new developer might totally rewrite class Y anyway, so there is no point in maintaining quality standards across the team.

marked as duplicate by gnat, Deduplicator, Greg Burghardt, user7519, Robert Harvey Jan 5 '18 at 15:51

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 3
    In a small shop, your manager is probably right that each individual will have their "own" code, which will often soon be thrown out or re-written if the developer leaves and that area of responsibility is taken over by another - the maintainability concerns of large firms are often alien here. But it's important to remember that "functional, performant, and secure" (and correct!) is the best measure of quality - I wouldn't get bogged down in measuring program quality by the mere appearance of source code (unless it is so inconsistent and badly structured that it is truly unfathomable). – Steve Jan 5 '18 at 12:24
  • 1
    see also How do I explain ${something} to ${someone}? – gnat Jan 5 '18 at 12:35
  • If you are writing code to have pretty code, then enforcing a style guide on a team is a high priority. If you are selling something then it is a lower priority. – Caleth Jan 5 '18 at 12:42
  • 2
    Title does not seem to match the body: "someone who says that quality [is a] good thing" vs. "He said that [...] 'quality' is not even an issue". – Josh Caswell Jan 5 '18 at 13:32
  • 1
    It is a self-fulfilling prophecy. Code that is hard to read has high chance of being rewritten by others. When enough rewrites happen, that is used as a justification for not spending too much time keeping it tidy, because the value of the software functionality (need) is perceived as low. – rwong Jan 5 '18 at 17:44
7

You seem to be conflating "quality standards" with consistent style. Your colleague is right that consistent style is much less important than readability and other relatively subjective measures. Style can vary from package to package and even sometimes from file to file as long as within a file it is consistent.

On the other hand, your colleague seems to be saying that code can be lower quality as long as it is maintained by only one developer. If he was actually saying it can have a unique style, but is otherwise highly readable, that's fine. If he was saying it can be sloppy and coupled because developers can somehow handle that if it's their own code, I strongly disagree. People can only hold so much in their head at once. We are constantly relearning even our own code.

  • It's a lot like writing in ordinary language, isn't it? At some point you expect to see punctuation, sentences, and paragraphs (i.e. some regard to structural patterns), and in any body of writing perceived as a unit you expect to see some consistency, but quality has little further to do with finer points of style - and some particularly elegant and expressive word-work, like poetry or rhetoric, may appear to defy any conventional style or easily-formulated rule. And word-work that is extremely precise in style, can nevertheless be inefficient, contradictory, vacuous, or at cross-purposes. – Steve Jan 5 '18 at 14:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.