Quotes About Quality

It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don't have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a development project than bad code.

Software has two types of value: the value of its behavior and the value of its structure. The second of these is the greater of the two because it is this value that makes software soft.

What makes a clean test? Three things. Readability, readability, and readability.

Woe to the poor developer who buckles under pressure and agrees to try to make the deadline. That developer will start taking shortcuts and working extra hours in the vain hope of working a miracle.

It is far more common to fight your way through terrible software designs than it is to enjoy the pleasure of working with a good one.

The only way to make the deadline—the only way to go fast—is to keep the code as clean as possible at all times.

Professionals use their powers for good and write code that others can understand.

There is no such thing as quick and dirty. Anything dirty is slow. The only way to go fast, is to go well.

We in this industry sorely need to increase our professionalism. We fail too often. We ship too much crap. We accept too many defects. We make terrible trade-offs. Too often, we behave like unruly teenagers with a new credit card. Martin, Robert C.. Clean Agile (Robert C. Martin Series) . Pearson Education. Kindle Edition.

Am I suggesting 100% test coverage? No, I'm not suggesting it. I'm demanding it. Every single line of code that you write should be tested. Period.

Agile is a process wherein a project is subdivided into iterations. The output of each iteration is measured and used to continuously evaluate the schedule. Features are implemented in the order of business value so that the most valuable things are implemented first. Quality is kept as high as possible. The schedule is primarily managed by manipulating scope.

You should be able to run all the unit tests with just one command.

QA and Acceptance Tests If QA has not already begun to write the automated acceptance tests, they should start as soon as the IPM ends. The tests for stories that are scheduled for early completion should be done early. We don't want completed stories waiting for acceptance tests to be written.

The tests fit the production code like an antibody fits an antigen.

refactored)    /**

if the bricks aren't well made, the architecture of the building doesn't matter much.

Am I suggesting 100% test coverage? No, I'm not suggesting it. I'm demanding it. Every single line of code that you write should be tested. Period. Isn't that unrealistic? Of course not. You only write code because you expect it to get executed. If you expect it to get executed, you ought to know that it works. The only way to know this is to test it.

It doesn't take a huge amount of knowledge and skill to get a program working. Kids in high school do it all the time. Getting it right is another matter entirely. When software is done right, it requires a fraction of the human resources to create and maintain.

Duplication may be the root of all evil in software.

The moral of the story is simple: Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.

Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.

Don't comment bad code—rewrite it." —Brian W. Kernighan and P. J. Plaugher1

When software is done right, it requires a fraction of the human resources to create and maintain. Changes are simple and rapid. Defects are few and far between. Effort is minimized, and functionality and flexibility are maximized.

The measure of design quality is simply the measure of the effort required to meet the needs of the customer. If that effort is low, and stays low throughout the lifetime of the system, the design is good. If that effort grows with each new release, the design is bad. It's as simple as that.