Emergent design, and refactoring in large projects
I bought a bunch of books at OOPSLA. Two of them are "Emergent Design" by Scott Bain, and "Refactoring in Large Projects" by Stefan Rook and Martin Lippert. Both are about refactoring and emergent design.
The first book is more motivational, a bit less technical (but still has lots of code), and easier to read. It describes how design patterns can make your system more flexible, but how refactoring is almost always necessary. It describes design principles necessary to create good design, and programming practices that make programs easier to understand and to change. It describes how testing fits in and makes refactoring practical. I enjoyed reading the book, will recommend it to people and loan my copy to students, but didn't learn anything new from it. Scott did a great job of describing the value of refactoring and design patterns. If you are not sure why these are important then the book will be useful to you. However, if you have been practicing them for some time then you will probably not learn more than better ways to argue your points.
"Refactoring in Large Projects" is a much more advanced book. It talks about architectural smells and how to fix them. It describes refactorings that take a long time to perform, and how to carry them out without any tool support and without driving other people crazy. It talks about tools, too, such as refactoring tools (which I use) and Sotograph, which seems very cool and which I will try to get. It has a chapter on refactoring relational databases, and a chapter on API refactorings. All the chapters are precise and have lots of detail. There are code examples. If you are new to refactoring then this book might be over your head, but if you have experience with refactoring then this book will expand your vision for what is possible.
Some people might think that these books are overselling the ability to change software. In fact, they are underselling it. Any kind of change is possible. You can change software to make it more secure, more safe, more reliable, and faster. You can change it to run faster on multicores. All change takes work. "Refactoring in Large Projects" shows the kind of bookkeeping and testing that is necessary to carry out large refactorings. But the biggest problem with most software systems is that their owners have let them get out of control, and have not practiced basic code maintance. If you follow the practices taught by these books, you'll be able to have your code under control.
