On a recent episode of the ATP podcast, one of the hosts lamented the idea that the PHP code that they’ve been writing has inexorably evolved and modernized—corrupted, even. Whereas PHP in its heyday was merely a giant messy ball of functions, newer versions of the language—and its practitioners who have stuck it out this entire time—have infested its culture with uncountable instances of the Gang of Four‘s (GoF) Design Patterns™, bestowing it one of the greatest insults that can befall a programming language: that it kinda, sorta looks like Enterprise Java.
For those unfamiliar with programming or, for programmers who haven’t come across this phenomenon, the GoF book introduces a number of patterns of Object-Oriented Programming (OOP), abstractions which are meant to make code more reusable and harder to misuse. To use a writing analogy, they’re little prewritten paragraph templates that provide a bit more structure to a group of sentences1, and it’s easy enough to string together multiple templates together to assemble full essays. Applying these techniques usually gets the job done, though it’s not the most creative or succinct endeavor, in writing prose or code.
The coding anti-pattern comes from the overuse of design patterns, whereby the added layers of programming patterns ends up spinning out meaningless abstractions and indirections that amount to noise. The AbstractWidgetFactory that spits out WidgetAdapters that needs another ProxyVisitor to use its Facade to update State—it’s the programming equivalent of corporate jargon, in that the cost of obfuscation has long outweighed any benefit in shared understanding. And of course, many such monstrosities are attributed to the aforementioned Java, Enterprise Edition.
Why, though?
For the sake of argument, let’s squelch the gut instinct that all things enterprise default to being laborious and farcical, that things in real life aren’t just variations on the pointy-haired boss. By definition, enterprise software is written, used, and sold to enterprises of significant size, which means that compared to customer-centric software or even software made for smaller businesses, there are a number common attributes that drive technological decision-making:
- User cohorts will likely be dominated by a couple of large clients
- Large clients don’t mind paying a lot for the functionality, as long as they get enough value for the expenditures
- But, large clients will also want a lot of say in feature roadmaps and expect some degree of custom development
- Enterprises value stability and reliability, with some degree of predictability, sometimes over agility and quick iteration and releases
- The people buying the software may not be its primary users
In aggregate, these attributes shape enterprise software development, both in how to build the team and then how that team should write its code.
One structural outcome with enterprise software shops is that they can afford to focus on niches, with a wider field of narrow enterprise opportunities, coupled with paying clientele which in turn promote more stable cash flows2 for potentially larger teams. Another outcome would be biasing towards system stability at the expense of rapid feature development, that priority is not necessarily given to the end-user (who isn’t the one paying for the software) but perhaps to administrative controls and monitoring and compliance. If the software sticks around for a while and proves its utility, it’s more important to keep clients’ familiar and established workflows and interfaces than embark on design changes.
Put together, the emphasis on abstractions and reusable code—as a form of communication between larger teams of engineers—with an bias towards overall system stability at the expense of development velocity starts to make the “Java EE” style of coding attractive. It’s not meant to be fast to write3, but it does reliably scale with a larger team. And when ensuring the right behavior is more important than fast development, the added layers of abstractions act as almost reinforcement, offering combinatorially more entry points for testing and validations. In fact, JavaScript went through the same type of coding style and cultural evolution as PHP, where the heavy OOP, design-pattern-influenced style of development has been adopted when complex web apps became common.
Not to say that it can’t go overboard.
