One thing that I constantly suffer from is letting the concept of perfection keep me from making progress on something. This happens not only in my software development but in my writing, my gardening, my golf game, almost everything. I have no idea how this came to be but it seems to be a pervasive element of my flawed character. I have found that it’s important to constantly focus on identifying when I’m trying to hard for the perfect. Progress, even negative progress, is almost always better than paralysis. I don’t seem to be alone in this characteristic. Take for example this post that is arguing, albeit in an extremely conflicted way, that the concept of Separation of Concerns in software development is useless because a perfect Separation of Concerns is impossible.
Anyone who says that a system must display perfect separation of concerns has either never written any large-scale software systems or is certifiable and can safely be ignored. The goal of writing software isn’t to produce perfect separation of concerns. That is only one of many possible means to get to the end result of long term maintainable software that produces some quantity of value. Writing any meaningful software without an eye on SoC results in a jumbled morass of unmaintainable and untestable crap. Does this mean that your HTML views should be completely dumb, devoid of logic? Of course not and no one with any real world experience would argue that. But if you don’t constantly strive to keep them as dumb as possible, you will end up with junk. It must be a constant focus, one that is in the forefront of every decision because if it is not, it is always easier to do what is wrong than what is right.
When I first read Atlas Shrugged, I was enthralled with the concept and philosophy behind the novel, that selfishness was inherently good and that every action should be judged based on one’s own self interest. Of course, I was 16 and frankly, the philosophy fit nicely into a 16 year old’s limited world view. As I got older, I began to realize that while acting in self interest as a general rule is good, taking it to the extremes that Objectivist philosophy did will result in a terribly narcissistic life.
The same thing happened when when I first discovered design patterns. Everything was a Factory. I loved Factories. Concrete Factories, Abstract Factories, Factory Factories, by God they were all fantastic. But slowly over time, I learned not every thing was a Factory and not every thing fit neatly into design patterns. But as a guiding rule, design patterns are good but it’s just as important to know when to not use one as it is to use one.
Separation of Concerns is the same. As an overall guiding principle, it is critically important. There are going to be times when ignoring it is in fact the right decision but those times are very few and far between and you better have a damn good reason for doing it. But not doing it because it’s never going to be possible to have a perfect separation isn’t one of those reasons.
June 27, 2011 at 6:54 pm
No offense, but I think you missed the point of my post. I did not say separation of concerns is useless – to the contrary, I said verbatim that it’s useFUL. The argument is not that it fails as a rule because it’s not possible to achieve perfection, it’s that sometimes the underlying reasons separation of concerns exists as a philosophy aren’t applicable. Sometimes we don’t make our application better with SoC, we just adhere to a guideline that doesn’t really apply to situations at a certain level of granularity. SoC should not win those arguments by default – there should be more thorough reasoning about whether a choice will negatively impact debugging or skinability or internationalization.
June 27, 2011 at 7:06 pm
My general feeling was that your post was a rant against people who treated SoC as the end, not the means. Looking back at my post, I wasn’t at all clear regarding that which is my bad. However, you also said SoC was “Bullshit”. It’s difficult for me to see how something can be both useful and bullshit (unless it’s fertilizer). I wasn’t necessarily disagreeing with you, more trying to clarify the usefulness of SoC.
Certainly, at any sufficiently fine level of granularity, most patterns and guidelines are going to disappear. But I think that most developers should err on the side of the patterns and guidelines because without them, what inevitably happens is a huge mess.
June 27, 2011 at 8:37 pm
Ah. I said it was bullshit in the same way a fairy tale is bullshit – it’s not “real” in the sense that it’s achievable, but serves an important purpose in keeping developers on the right track, like telling your kids stories about evil witches who live in the woods hopefully helps keep them out of the woods where they may get lost or break their legs or something. Parents BS their kids by telling them fairy tales, but do it with the best intentions and because it’s easier than explaining the complexities of what they really want them to do and why. We do the same thing with beginner developers and separation of concerns.
The point about not erring on the side of patterns/guidelines is that we’re not beginner developers (or, even if we are, won’t always be). That shorthand for the host of things we want to accomplish bears examination when it’s no longer clearly applicable. Rather than just saying, this isn’t clear, so go with the best separation of concerns, we should be examining the specifics of why separation of concerns is important at that level and why it’s difficult to achieve and weighing those, not patterns or buzzwords.