Separation Of Concerns - It's Not Just For Code

As developers, we're generally familiar with the idea of SoC. It's basic modular design, no matter how you describe it. Complex things are made of many simple things; Having many small pieces is better than having one large piece; Each segment of code should do one thing and only one thing and do it well; etc. Good developers keep this in mind when writing their code. (We all know that sometimes business requirements get in the way of good design practices, but you can't really blame that on the developer.)

But it seems all to common that organizations fail to maintain proper SoC when building their infrastructures. Maybe too many managers drink the Microsoft Kool-Aid, maybe one influential blow-hard forces his ignorant will on the group, the reasons go on and on. All too often, it seems that businesses look so favorably upon tools that "integrate" that they overlook the fact that these same tools often "interdepend." That is, when your infrastructure is all set up, you're suddenly locked in to a design that limits what you can actually do.

(Let me take a small break here to mention that I may not actually have much of a point here. It's entirely possible that I'm just teetering on the edge of a bitching-session and what I have to say isn't of particular value. But I'm going to continue anyway.)

I'll start with a purely hypothetical example. This example may not actually be literally plausible, as I'm not so intimately familiar with the tools it references and their integration options. But the concept being addressed is clear.

Suppose you are an employee of a given organization and you need to build a document to send to a client. For the sake of urgency, it's a big client. And this client is considering your organization as an option among several competitors. No pressure, though. So you fire up Microsoft Word and start composing. It sure is a great tool, isn't it? In fact, your organization loves the Microsoft Office family of products so much that they forked over all the cash they could for all the fully-integrated solutions Microsoft could offer them. It's so easy and convenient for you now and you can do it all from anywhere you need. Sounds good, right?

In this document you want to visually represent some ideas. So you fire up the integration with Microsoft Visio and put together some wonderful charts and graphics to clarify what you're saying. You use various other plugins and whatnot to decorate your document even more, making it as clear and professional as possible. All the while you're basking in the wonderful set of fully-integrated tools that allow you to do this. You finish your document and proudly send it off to the client.

They reply saying that they can't open the attachment. They asked for a Word document, and you sent them something that looks like a Word document, but when they try to open it they get errors about the version of Word and something about Visio, which they don't even have, and even when they get it to open it seems to be missing a lot of information.

Did you have to convert something when embedding it into your document? Did you have to save it in a special way? Well, yes and no. In that particular scenario, yes, you should have performed some extra step to "flatten" your document and save it all down in a more transportable format. But, more to the point, no, you should not have had to do anything extra. Your organization's fully-integrated solution failed. The client wanted a document, but what you ended up sending them was a document with external dependencies.

Don't feel bad, it happens to lots of companies. And unfortunately it ends up being a serious hindrance for a lot of developers working for those companies. And it leads to such gems as this:

My Manager: We use [insert tool here] because it integrates with Visual Studio, makes things a lot easier.
Me: Then I guess we're going to need [insert tool here] installed on the build server if we want any kind of continuous integration.
My Manager: No can do, the license would be too expensive.
Me: Well, if we switch to [other tool], which is free even for commercial use, then we can completely script it out and automate it. We're not really deeply vested in [insert tool here] yet anyway, so switching now wouldn't be difficult.
My Manager: No way, we already spent a lot of money on [insert tool here]. The decision was already made.
Me: Yes, but it's getting in the way. It... doesn't appear to be making things easier at all.
My Manager: But it integrates with Visual Studio, which is what we wanted.
And so on, you can see where this is generally going. You can plug in your values of choice... testing libraries, source control, etc. The problem is always the same: integration to the point of interdependency.

And, honestly, why the hell would you want everything to happen inside your IDE? This makes your IDE a very integral (and very heavy) part of your build and deploy process. Do you want to install Visual Studio on the production servers in order to get certain pieces to work? Of course not. Then de-couple that shit right now.

Source control is a file system operation. It tracks changes to files. That's it. It doesn't need to know that different files mean different things in different contexts. It doesn't care. Your project file is just an XML file. It's not some magical container that the source control system should use to determine what's been changed.

Updating, building, deploying, testing, etc. Everything you do should be a separate and discreet component. Your QA department shouldn't have to open Visual Studio to run their tests. Your production deployment people shouldn't have to open Visual Studio to friggin' copy files to a server.

This isn't to say you can't have tools that integration. You just need to know what you're getting into. Take, for example, the build server at my last job. It ran a product called TeamCity (you may recognize them as the makers of ReSharper), which integrated with Subversion for source control. So your build server can watch your code and automatically update and run builds accordingly. Makes things easier, right?

Yes, it does. Because TeamCity doesn't need Subversion, and Subversion doesn't need TeamCity. You can switch to a different continuous integration tool or a different source control with minimal effort. Does this require that developers need to step outside of the IDE (aka, their comfort zone) once in a while to perform tasks? You bet your ass it does. And if they can't do that then you need to seriously question the difference between skilled developers and cert-monkeys.

You pay a hell of a lot more for your developers than you do for the tools they use. Which of the two should be in charge of the other?