Why do code quality discussions evoke strong reactions? [closed]

Question

One obvious answer for the Stack Overflow part is that it isn't a forum. It is a database of questions and answers, which means that duplicate questions are attempted avoided.

How many different questions about code quality can you think of? That is why there aren't 50,000 questions about "code quality".

Apart from that, anyone claiming that conference speakers don't want to talk about unit testing or code quality clearly needs to go to more conferences.

I've also seen more than enough articles about continuous integration.

There are the common excuses for not writing tests, but they are only excuses. If one wants to write some tests for his/her new code, then it is possible

Oh really? Even if your boss says "I won't pay you for wasting time on unit tests"? Even if you're working on some embedded platform with no unit testing frameworks? Even if you're working under a tight deadline, trying to hit some short-term goal, even at the cost of long-term code quality?

No. It is not "always possible" to write unit tests. There are many many common obstacles to it. That's not to say we shouldn't try to write more and better tests. Just that sometimes, we don't get the opportunity.

Personally, I get tired of "code quality" discussions because they tend to

• be too concerned with hypothetical examples, and are far too often the brainchild of some individual, who really hasn't considered how aplicable it is to other people's projects, or codebases of different sizes than the one he's working on,
• tend to get too emotional, and imbue our code with too many human traits (think of the term "code smell", for a good example),
• be dominated by people who write horrible bloated, overcomplicated and verbose code with far too many layers of abstraction, or who'll judge whether code is reusable by "it looks like I can just take this chunk of code and use it in a future project", rather than the much more meaningful "I have actually been able to take this chunk of code and reuse it in different projects".

I'm certainly interested in writing high quality code. I just tend to be turned off by the people who usually talk about code quality.

Code review is not an exact science. Metrics used are somehow debatable. Somewhere on that page : "You can't control what you can't measure"

Suppose that you have one huge function of 5000 lines with 35 parameters. You can unit test it how much you want, it might do exactly what it is supposed to do. Whatever the inputs are. So based on unit testing, this function is "perfect". Besides correctness, there are tons of others quality attributes you might want to measure. Performance, scalability, maintainability, usability and such. Did you ever wondered why software maintenance is such a nightmare?

Real software projects quality control goes far beyond simply checking if the code is correct. If you check the V-Model of software development, you'll notice that coding is only a small part of the whole equation.

Software quality control can go to as far as 60% of the whole cost of your project. This is huge. Instead, people prefer to cut to 0% and go home thinking they made the right choice. I think the real reason why so little time is dedicated to software quality is because software quality isn't well understood.

• What is there to measure?
• How do we measure it?
• Who will measure it?
• What will I gain/lose from measuring it?

Lots of coder sweatshops do not realise the relation between "less bugs now" and "more profit later". Instead, all they see is "time wasted now" and "less profit now". Even when shown pretty graphics demonstrating the opposite.

Moreover, software quality control and software engineering as a whole is a relatively new discipline. A lot of the programming space so far has been taken by cyber cowboys. How many times have you heard that "anyone" can program? Anyone can write code that's for sure, but it's not everyone who can be a programmer.

EDIT *

I've come across this paper (PDF) which is from the guy who said "You can't control what you can't measure". Basically he's saying that controlling everything is not as desirable as he first thought it would be. It is not an exact cooking recipe that you can blindly apply to all projects like the software engineering schools want to make you think. He just adds another parameter to control which is "Do I want to control this project? Will it be needed?"

• Laziness / Considered boring
• Management feeling it's unnecessary - Ignorant "Just do it right" attitude.
• "This small project doesn't need code quality management" turns into "Now it would be too costly to implement code quality management on this large project"

I disagree that it's dull though. A solid unit testing design makes creating tests a breeze and running them even more fun.

Calculating vector flow control - PASSED
Assigning flux capacitor variance level - PASSED
Rerouting superconductors for faster dialing sequence - PASSED
Running Firefly hull checks - PASSED
Unit tests complete. 4/4 PASSED.

Like anything it can get boring if you do too much of it but spending 10 or 20 minutes writing some random tests for some complex functions after several hours of coding isn't going to suck the creative life from you.

Why is code quality so unpopular?

Because our profession is unprofessional.

However, there are people who do care about code quality. You can find such-minded people for example from the Software Craftsmanship movement's discussion group. But unfortunately the majority of people in software business do not understand the value of code quality, or do not even know what makes up good code.