Premature abstraction

Resisting premature abstraction is as important as abstraction itself.

Robert C. Martin, "OCP: The Open-Closed Principle", in Agile Software
Development: Principles, Patterns, and Practices, 109.

The source code is the design

[...] programming is not about building software; programming is about designing software.

Jack Reeves, "What is Software Design?", C++ Journal, Vol. 2, No. 2, 1992.

I strongly recommend reading the entire paper.

Keeping the design as good as it can be

Agile developers [...] never say "We'll go back and fix that later." They never let the rot begin.

[...]

The attitude that agile developers have toward the design of the software is the same attitude that surgeons have toward sterile procedure. Sterile procedure is what makes surgery possible. Without it, the risk of infection would be far too high to tolerate. Agile developers feel the same way about their designs. The risk of letting even the tiniest bit of rot begin is too high to tolerate.

[...]

Professionalism dictates that we, as software developers, cannot tolerate code rot.

Robert C. Martin, "What is Agile Design?", in Agile Software Development:
Principles, Patterns, and Practices, 94.

Symptoms of poor design

1. Rigidity — The design is hard to change.
2. Fragility — The design is easy to break.
3. Immobility — The design is hard to reuse.
4. Viscosity — It is hard to do the right thing.
5. Needless Complexity — Overdesign.
6. Needless Repetition — Mouse abuse.
7. Opacity — Disorganized expression.

These symptoms are similar in nature to code smells, but they are at a higher level. They are smells that pervade the overall structure of the software rather than a small section of code.

Robert C. Martin, "Agile Design", in Agile Software Development:
Principles, Patterns, and Practices, 85.

Refactoring

Every software module has three functions. First, there is the function it performs while executing. This function is the reason for the module's existence. The second function of a module is to afford change. Almost all modules will change in the course of their lives, and it is the responsibility of the developers to make sure that such changes are as simple as possible to make. A module that is hard to change ir broken and needs fixing, even though it works. The third function of a module is to communicate to its readers. Developers unfamiliar with the module should be able to read and understand it without undue mental gymnastics. A module that does not communicate is broken and needs to be fixed.

[...]

I can't stress this enough. All the principles and patterns in this book come to naught if the code they are employed within is a mess. Before investing in principles and patterns, invest in clean code.

Robert C. Martin, "Refactoring", in Agile Software Development:
Principles, Patterns, and Practices, 31-42.

The future of software engineering

The tar pit of software engineering will continue to be sticky for a long time to come. One can expect the human race to continue attempting systems just within or just beyond our reach; and software systems are perhaps the most intricate of man's handworks. This complex craft will demand our continual development of the discipline, our learning to compose in larger units, our best use of new tools, our best adaptation of proven engineering management methods, liberal application of common sense, and a God-given humility to recognize our fallibility and limitations.

Frederick P. Brooks, Jr., "The Mythical Man-Month after 20 Years", in The Mythical Man-Month (Anniversary Ed.), 288-289.

Tests: beyond verification

I must admit that my first contact with software testing was not so long ago. Since them I've been increasingly impressed with how powerful a good suite of tests can be for verifying if we are delivering the expected product. Yet, as Uncle Bob well asserts, verification is just one of the benefits of writing tests. This is especially true when we're talking about TDD. There are at least four other (arguably more important) reasons that motivate writing tests first whenever possible:

• Avoid regressions. A well constructed suite of tests gives much more freedom when we need to extend or refactor existing code. It gives us a safe guard against changes that can inadvertently break the working software.
• Documentation. I've never thought about this before, but tests are a form of living and executable documentation. They have to stay current, otherwise they'll break. Besides, they show how to work with the code, instead of just inform how to do it. They're not only a form of documentation, but a very good one.
• Better design. Writing tests forces us to think by the point of view of the caller of our code. Not only that, it forces us to write client code for our own code. This can have beneficial impacts in our architectural decisions because many issues related to the software interface become more evident as we write the tests (and ahead of time if we write them first, which is even better).
• Better implementation. This topic is closely related to the previous one, but deserves its own section in face of the great improvement that it can represent for a software project. Citing Uncle Bob again: "the act of writing tests first forces us to decouple the software!". Tightly coupled software is bad. It's hard to maintain, hard to extend and often hard to understand. It's also very hard to test. This way, in order to test it we have to decouple it. The more testable it is, the more decoupled it is. And the more decoupled it is, the better designed and implemented it is.

For more details about these topics I strongly recommend reading chapter 4 of Agile Software Development: Principles, Patterns, and Practices. Words of wisdom from Robert Martin.

Individuals and interactions over processes and tools

Working well with others, communicating and interacting, is more important than raw programming talent. A team of average programmers who communicate well are more likely to succeed than a group of superstars who fail to interact as a team.

Robert C. Martin, "Agile Practices", in Agile Software Development:
Principles, Patterns, and Practices, 4.

[...] the quality of the people on a project, and their organization and management, are much more important factors in success than are the tools they use or the technical approaches they take.

Frederick P. Brooks, Jr., "The Mythical Man-Month after 20 Years", in The Mythical Man-Month (Anniversary Ed.), 276.

List of books (1st edition)

• 
  Design Patterns: Elements of Reusable Object-Oriented Software
  
  A reference on the software design field, the famous GoF book is worth its status. It provides a solid ground for thinking about software projects, from the architecture to implementation and refactoring. Even if not all the patterns or their categorization are unanimously accepted (see, for example, Steve Yegge commentaries about the Interpreter pattern or the various discussions about the Singleton pattern on the web), you should know them in order to take part in the debates and decide when to apply them or not. The book organization is exceptional, which helps a lot in a book about patterns. A must-read for every software engineer.
• 
  The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition
  
  Is it possible that a book written 40 years ago, a 30-year paper and a review of both made 20 years ago are still relevant today? The Mythical Man-Month, Anniversary Edition proves that it is. The original content is full of good observations around the essential and accidental (in Fred Brooks' own words) aspects of the software task. The anniversary edition adds a copy of the excellent paper No Silver Bullet, published in 1985, besides new commentaries by the author. In a field where many things change fast, The Mythical Man-Month passes the test of time with great praise.
• 
  Swarm Intelligence
  
  The focus of this book is the PSO algorithm. Nevertheless, it also offers a good introduction, in the first part of the book, to evolutionary algorithms in general, covering historical and even some philosophical questions related to the subject. The second part shows the PSO algorithm itself and brings comments about the many ways to optimize it. The algorithm is short and simple, so it's not hard to understand (although they could have simplified it even more by using a different notation instead of greek letters). Some reviewers consider the first part as ramblings, but I have to admit I like it better. Anyway, the book as a whole offers a very good content.