Composite Architecture - The Open Close Principle as applied to system architecture

time to read 3 min | 592 words

My post about tests got the expected response, and I think that Denis's comment is a good sample of the type of feedback that I got: won't be able to ship periodically at sustainable costs and quality without relevant engineering practices like unit tests, refactoring and continuous integration...

Despite several attempts in repeating that, it seems like many people missed the part that I explicitly stated: I wasn't trying to say that tests are not valuable. I was trying to talk about the blind faith that people put in tests.

Now, to Denis's comment. Yes, I would be able to ship periodically without tests.

I am not talking in the air, I have the practical experience and two years of a running project to back me up on that. We had a CI process in place, which deploy the application to a staging server, and that was it. Refactoring... is not a subject that I can talk about in the context of this application without first explaining the architecture.

I came to that project shortly after finishing up a project that was... problematic. And I was determined to avoid the same mistakes. One of the first thing that we did was to define the core parts of the system, and build just enough of that to serve us. So far, this is normal, except that we added a tiny twist.

We applied the Open Close Principle as a holistic view for the entire project. If we needed to change a line of existing code, that was a bug, and we had to refactor that area of the system to make sure that the next time we need to change this, we wouldn't have to change existing code. Adding a new feature consisted entirely of adding new code.

We didn't touch existing code. Well, not very often, to be honest. This is the same project where I spent three months straight without even once going to the infrastructure directory, indeed, after three months we run into a problem, and it took me 10 minutes to remember that we are using a container in the app, and that the new class didn't match our convention, so Binsor did not register it.

A lot of my ideas about zero friction development came directly from this project.

Because we always wrote new code, and each feature was isolated from all other features, we were able to keep a rapid pace of development for the lifetime of the project. I mentioned that we didn't have automated tests, we didn't feel the lack. Off the top of my head, I can't recall any regression bugs that we had, except with infrastructure going bad (IT admins removing our shared storage, BizTalk changes we weren't told about, stuff like that).

I am pretty sure that there were some, but I can't think of any, so that put them at a very low number. And some stats about the project. It is running for 2 years (I left after the first year, and the team continued to provide new features and releases after I left), currently at over 200,000 lines of code, is considered a major success from the business point of view and its scope has tripled since the original inception.

And just to reiterate, I like tests. I think that they are important and that they have proven themselves in the field. BUT, They aren't a silver bullet, having them wouldn't make the project succeed. And not having tests wouldn't make the project fail.