Quotes from Robert C. Martin

Structured programming is discipline imposed upon direct transfer of control.

Object-oriented programming is discipline imposed upon indirect transfer of control.

It is no longer sufficient that every programmer does what is right in their own eyes. Some disciplines, standards, and ethics will come. The decision before us today is whether we programmers will define them for ourselves or have them forced upon us by those who don't know us.

Functional programming is discipline imposed upon variable assignment.

Objects hide their data behind abstractions and expose functions that operate on that data. Data structure expose their data and have no meaningful functions.

If we really want to spend our days programming, we are going to have to learn to talk to—people.1

If its dependencies are inverted, it has an OO design. If its dependencies are not inverted, it has a procedural design.

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.

God is in the details, said the architect Ludwig mies van der Rohe.

Software architecture is the art of drawing lines that I call boundaries. Those boundaries separate software elements from one another, and restrict those on one side from knowing about those on the other.

Learning to write clean code is hard work. It requires more than just the knowledge of principles and patterns. You must sweat over it. You must practice it yourself, and watch yourself fail. You must watch others practice it and fail. You must see them stumble and retrace their steps. You must see them agonize over decisions and see the price they pay for making those decisions the wrong way.

Recall that the goal of an architect is to minimize the human resources required to build and maintain the required system.

A stitch in time saves nine. The early bird catches the worm. Don't put off until tomorrow what you can do

Which kinds of decisions are premature? Decisions that have nothing to do with the business requirements—the use cases—of the system.

creative output depends on creative input.

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.

Why does good code rot so quickly into bad code? We have lots of explanations for it. We complain that the requirements changed in ways that thwart the original design. We bemoan the schedules that were too tight to do things right. We blather about stupid managers and intolerant customers and useless marketing types and telephone sanitizers. But the fault, dear Dilbert, is not in our stars, but in ourselves. We are unprofessional.

Because this ratio is so high, we want the reading of code to be easy, even if it makes the writing harder. Of course there's no way to write code without reading it, so making it easy to read actually makes it easier to write.

The tragedy is that the architects, by making a premature decision, multiplied the development effort enormously.

When classes lose cohesion, split them!

is not the language that makes programs appear simple. It is the programmer that make the language appear simple!

In Scrum, we make everything visible. We air our dirty laundry. We are honest about the state of our code because code is never perfect. We become more fully human, more worthy of the divine, and closer to that greatness in the details.

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

Cuteness in code often appears in the form of colloquialisms or slang. For example, don't use the name whack() to mean kill(). Don't tell little culture-dependent jokes like eatMyShorts() to mean abort(). Say what you mean. Mean what you say.