I just finished reading Release It!. I know that Ayende is really fond of this book, and I can't blame him.
Like most books I've read over the last couple of years, this book is not about the technology -du-jour. It's about how to design and build software that stays up-and-running in a production environment. This is a really important topic. We like to believe that the environment in which we build and test our software is good enough. But let's face it, it never ever gets close to the final production environment in which our software has to live, despite the massive amounts of effort we and others put in setting up a decent development/acceptance environment. In order to let our software survive in a production environment, we as software engineers need to incorporate some patterns and practices in order to achieve this goal.
Designing our software for production is a whole different ball game though. Normally we aim for passing QA, fulfilling the functional requirements without considering how the resulting software system behaves in production and with how much capacity.
A while ago, I was listening to this episode of .NET Rocks with Udi Dahan about scaling web applications. Also, Colin kindly pointed me to this article on Udi's blog that really struck a nerve. I really like exploring these kind of architectures. It's based on years of experience and that is the kind of stuff I want to learn.
The same goes for this book. It's based on years and years of experience about keeping medium to large sized software systems alive in production. It's full with patterns and anti-patterns of stability, capacity and operations.
I couldn't help but noticing how much the author mentioned the importance of loosely-coupled software designs. Although this sole aspect of a software system alone is probably not enough, my personal experience shows that loosely coupled systems are much more stable in production than a tightly coupled software system.
Tight coupling allows cracks in one part of the system to propagate themselves - or multiply themselves - across layer or system boundaries.
Something I've seen a lot over the past couple of years, and also at my current employer, is when a software system finally makes it into production, the stakeholders consider it finished. As soon as a piece of software (read massive investment) hits a production server, it is left alone and considered an artifact of the past. To me, this is just foolish.
The true birth of a system comes not on the day that design and development begins, or even when the project is conceived, but on the day it launches into production. This is a beginning, not an end. Over time, the system will grow and mature. It will gain new features. It will lose defects, and perhaps gain some too. It will become what it was meant to be, or, even better, it will become what it needs to be. Most of all, it must change. As system that cannot adapt to its environment is stillborn.
Rome didn't get built in one day either. Why should this be the case for a valuable software system? This partly comes back to how tightly coupled a software system is designed.
Anyway, in case you didn't notice by now: go buy and read this book. I have written down so much stuff while reading it, that I probably have enough material for writing blog posts until the end of this year. The book practically pays for itself ;-).
I welcome Release It! to my growing favorite book list. The next book I'll be reading is Clean Code, which got delivered earlier this week. I've been really anxious to read it.
Till next time,
Jan, the literate
