In Two lessons for the price of one, Assaf over at Labnotes referred to No Wonder Enterprise Software Sucks^H^H^H^H^H Is Low Quality. He quoted the following passage:

My point is that the architectural complexity of these applications inhibit a person’s understanding of the code. . . . Without actually doing anything, applications are becoming too complex to understand, build, and maintain.

The original piece of writing about the low quality of enterprise software by Travis Jensen is worth a read, but Assaf’s own brief take on the matter is all I need here:

Every layer makes perfect sense in isolation. The cracks start showing when you pile them up into a mega-architecture, and you can clearly see how some of the layers cancel each other out.

Object Oriented Programming

One of the oft-cited benefits is the ability to “reuse code” without having to rewrite it. This is accomplished by way of encapsulating code with data in a manner that provides a sort of discrete entity to which one can refer over and over again within a program. That encapsulation, along with the protection (that is, protecting the code and data inside an object from contamination by improper access) that OOP offers, provides other benefits as well.

Among these other benefits is increased sustainability of large, complex projects, with many programmers who need not even be familiar with each others’ work (or names, for that matter) helping to develop the overall project. Because object oriented design allows a program to be more fully and easily broken down into separate, largely independent chunks than many other programming styles allow, it is easier to specify an API, then assign its implementation to a single team of programmers, and send them off to finish that task. These groups, in turn, can further break down their own chunks of the overall system into smaller chunks, and hand those sub-chunks off to sub-teams or individuals.

As large, complicated software systems like this evolve over time, they tend to grow in terms of total number of chunks that make up the whole system. Furthermore, mediocre (or even downright crappy) code can flourish within carefully encapsulated and protected classes without ever having to be judged by outside eyes; that is to say, one doesn’t even need anyone outside the team or programmer that developed a single segregated piece of the whole system to view the code, as long as it “works”. Nobody working on any of these individual chunks needs to know anything about the project’s Big Picture, either. There isn’t even any particular need to have a unifying architectural style, and with big enough projects, it can quickly become nigh-impossible to impose such a unifying architectural style anyway.

The Pattern

Can we see the pattern yet?

A while back (like, two years ago), I wrote a consideration of the social effects of OOP on how software has “advanced” titled OOP and the death of modularity. In it, I may have seemed to say the opposite of what I’ve been implying so far, but the very perspicacious among you may notice this isn’t the case. In fact, both OOP and the death of modularity and this piece point out basically the same problem, but in different ways: that software is getting bigger and more complicated without actually separating concerns in as meaningful a way as it could — as, in fact, certain older development philosophies (like “the Unix philosophy”) provided significantly better modularity and significantly reduced complexity.

Of course, I wasn’t then, and I’m not now, saying that object oriented programming is the proximate cause of the ills of bloated enterprise software.

What I’m saying is that people are the proximate cause — people who don’t know what the hell they’re doing. These people accept all the marketing for OOP, which states that it’ll make your code more modular and more stable and just generally better. It won’t. It will help you do good things for your code if you apply it intelligently, and if you don’t use it even when you shouldn’t.

OOP still isn’t a silver bullet. Nor is FP, for that matter. They’re just tools that can help when properly applied. Don’t make the old mistake of assuming that when you have a hammer, everything’s a nail. Sometimes it’s a hex nut, and you need a different tool.

. . . and don’t assume that just because you’re using OOP techniques you don’t have to get actually good programmers to do the work for you. As Paul Graham put it:

Object-oriented programming offers a sustainable way to write spaghetti code.

It doesn’t force you to do so — but it sure does make spaghetti code a lot more attractive.

OOP didn’t do this to us; we did it to ourselves. OOP just held our hats.