Points of Comparison

In medicine, certain conditions are known as “spectrum disorders” because they’re not simple binary conditions from which you suffer or don’t suffer. Rather, these conditions exist along a spectrum of severity. One can suffer from a condition slightly or severely, and the difference might manifest as entirely different symptoms and require entirely different treatments.

Web content management can be the same way.

To demonstrate this, it might help to examine the aspects of content management as a series of comparisons or dichotomies. By understanding the range of available options along a particular axis and what the boundaries are on either side, we can begin to understand the full breadth of options.

There are numerous facets to systems, implementations, and practices that are simply not black and white. In fact, there are few absolutes in content management. What’s correct in one situation is clearly wrong in another. What’s right for one organization would be a disaster at another. The key to making a CMS work is making the right decisions for your situation, which often makes it seem like more art than science.

Furthermore, the fundamental differences we’re going to explore here make it difficult to compare CMSs accurately. Instead of apples to apples, you end up with apples to pot roast. For example:

• Drupal Gardens is a hosted service built in PHP using a coupled model, offering few marketing tools and little in the way of customization or implementation.
• Ingenuix is an installed system built in ASP.NET using a decoupled model, offering marketing automation and deep customization and requiring significant implementation.

Technical comparisons of those two systems are difficult because they lie at opposite ends of multiple axes of comparison:

• One is hosted, the other is installed.
• One is built in PHP, the other is in .NET (and since one is hosted, often users simply won’t care that it’s built in any particular language).
• One is coupled, the other is decoupled.
• One is commercial, the other is open source.

The correct solution for any particular aspect of your situation will fall somewhere between two ends of the scale. Therefore, we need to understand what each end of that scale looks like.

Target Site Type

Different CMSs are targeted at different types of sites. The range in intended end results is vast. A “website” could be any one of the following:

• A small, static marketing site for a dental office
• A multinational newspaper publishing hundreds of articles a day
• A single-author blog for a technology writer
• An intranet for a medium-sized accounting firm
• An extranet for the dealers of a farm implement manufacturer
• The product documentation library for a software developer
• The course materials and syllabi for a small university
• An online community and social network for owners of Porsches

There’s just no easy way to draw hard boundaries around what we mean when we say “website.” Content management is a problem for all of the examples given here, and CMSs exist that specialize in each of them. The CMS used for the dental office could conceivably be used to power the newspaper’s website, though it likely wouldn’t work very well.

A CMS is very rarely promoted as a general system to solve all problems of every type of site. A particular CMS is usually targeted at a particular type of problem. Some problems might be broad, some might be narrow, but the architects behind a CMS are pursuing a target problem to be solved. It’s usually in your best interest to match the intention of your CMS as closely to your problem as possible.

Systems Versus Implementations

It’s important to separate a content management system from a CMS implementation. An implementation is the process by which a CMS is installed, configured, templated, and extended to deliver the website you want.

Unless you build your CMS from scratch, you are not the only one using it. Other organizations are using the same software to solve different problems and deliver different types of websites, so it’s not going to be preconfigured to do any one thing particularly well. This means a necessary step is the initial effort of adapting the CMS to do exactly what your organization and circumstances require from it.

To revisit our homebuilding analogy from the first chapter, a pile of wood and a set of tools are not the house you want. Ted the Contractor exerts effort to use the tools to build the house. This is a one-time effort, and the final product is a completed house. Furthermore, Mike the Contractor might use the same materials to build an entirely different house.

An implementation is a significant programming project. The skillsets required are not unlike those for other development efforts: you need designers, developers, frontend specialists, project managers, and experts in the CMS itself. Organizations sometimes do their own implementations, but it’s often contracted out to a development firm that specializes in the CMS being implemented.

The expense of the implementation is usually the largest expense in the budget, far eclipsing even the license fees for a commercial CMS. The rule of thumb differs depending on who states it, but implementation fees are usually some multiple of the licensing cost of the software.

The implementation should be considered at least as important to the success of the project as the CMS software itself. There are many decisions to make during an implementation, and two different implementations of the same website using the same CMS might bear little resemblance. Any of these decision points can be implemented well or poorly, and those results will have a huge impact on the final result.

The most perfect CMS in the world can be rendered all but useless by a poor implementation. And while I concede there are some CMSs that are irredeemably poor or inappropriate for a given situation, I’ve seen many stellar implementations that were able to make mediocre CMSs work for a particular project.

Platform Versus Product

If we consider a CMS a range of functional “completeness,” the extremes might look like this:

• No CMS functionality at all, just a raw programming platform
• A fully functional CMS ready to go out of the box, complete with pre-built features to solve all your content problems with no changes

In between these two extremes, we can insert a third option:

• A programming framework providing flexible API access to common content management features and functions that can be used to develop your own solution, along with a default user interface and configuration to support common needs

Tony Byrne from Real Story Group has referred to this type of CMS as a “platform,” and the opposite prebuilt extreme as a “product.”

Platform-style systems are designed to be rearranged and customized during implementation. Product style systems are designed to solve specific problems quickly and without significant effort.

Platform-style systems are flexible but effort-intensive. Product-style systems are rigid but supposedly easy to implement.

It’s a natural trade-off. With a product, you trade reduced implementation costs for agreeing to accept how the system works. With a platform, you trade increased implementation costs for more flexibility and control.

Many vendors market their systems as products that are ready to solve all content problems out of the box with very little effort. The inverse is more rare: very few vendors want to be known as providing systems that require heroic customization and programming in order to build a website. While this may appeal to hardcore developers, they’re not usually the people making purchasing decisions.

The platform orientation of a system can be used to explain the extent and expectation of the system’s extensibility and customizability. Some CMSs are highly customizable, and this is absolutely expected in every implementation. Other CMSs are designed to go in as purchased and provide few options for customization.

This is simply due to the fact that every CMS vendor or development community has use cases (literally, “cases for use”) in mind when their system is developed. Whether these use cases are explicitly recorded somewhere or not, every CMS is created to solve a set of theoretical problems. One system might be designed to manage a blog, another might be designed to manage an intranet.

Your ability to use a product-style CMS to solve your problems depends highly on how closely your situation resembles these theoretical problems. If they don’t match up, then your ability to use this CMS for a purpose outside its original designed intention depends highly on the extensibility of the CMS.

Often, a product-style system will provide prebuilt functionality that gets very close to the desired solution of one of your problems. In situations where 90% isn’t enough, the product will have to be customized to bridge the gap. Some systems are designed to allow this, and others are not.

Open Source Versus Commercial

With most software, both commercial (paid license) and open source options exist. This is probably more true of content management than any other genre. Literally thousands of options exist, and extremely common open source CMS platforms like WordPress and Drupal power a significant percentage of websites worldwide.

Given the installed base and depth of use, open source CMSs are generally well tested, feature rich, and have a large volume of contributed code and modules. The availability, responsiveness, and accuracy of community support is usually quite high, but varies widely.

An open source CMS project can usually trace its roots back to a developer champion who originally created it to solve a specific personal or professional problem. Very few systems are “clean sheet” designs built from scratch with the intention to be distributed. Rather, they begin as small, internal projects and grow until reaching critical mass and being contributed to the open source community for continued development.

This results in a fair amount of developer-centrism – some of them are written by developers, for developers. Most open source projects subconsciously evolve to be interesting and desirable for developers first, then everyone else second. Editors and marketers are often the second-class citizens in these cases.

This results in a common pattern – an “open source syndrome,” if you will – characterized by:

• Platform-style systems with highly extensible APIs
• Emphasis on the database-like features of a CMS, such as content modeling and aggregation
• An assumption that a developer will always be available for implementation and management
• Average to below-average user interfaces with some rough edges
• A tendency to overwhelm editors with numerous options
• An emphasis on generalization, configurability, and elegance of code
• Lack of higher-end marketing or delivery tools

Open source systems normally go through large amounts of teardown and reconstruction over time. For many developers, the code and process of solving content problems is an end goal in itself. Rearchitecting the system to be more elegant, efficient, or generalizable is held to be a worthwhile effort.

Over a decade ago, Joel Spolsky of Fog Creek Software was complaining about this exact problem:

We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.

Commercial systems, on the other hand, have a built-in limitation – they need license fees, so the end goal is selling the software, not architecting it. Clearly, this can result in some bad decisions and wallpapering over of genuine technical problems, but it also results in more end-user-focused development, because features for the end user is what sells licenses. At the end of the day, commercial software has to ship for the company to stay in business.

New open source systems are quite common, though as the market is more crowded now, it’s harder and harder for any new system to gain any traction and achieve a significant installed base. Consequently, the most successful open source CMSs are also some of the oldest.

PHP-based systems form the lion’s share of the open source CMS landscape. The three most common CMSs of any license style in popular use (WordPress, Drupal, and Joomla! ) are all PHP systems.

Systems lose traction and developer support primarily due to the inability of their underlying technology stack to attract new developers – there are dozens of systems from the mid-'90s written in Perl, ColdFusion, and (occasionally) C++ that are slowly dying off. New Java-based open source systems are also becoming more and more rare as Java becomes a less popular web framework.

Using an open source CMS provides numerous benefits:

• The software is free.
• Community support is often plentiful.
• Contributed code is often available to solve common problems.
• Developers and contractors are usually highly available.

But some drawbacks exist too:

• The “open source syndrome” we discussed tends to make these systems less attractive to non-editors.
• Ubiquitous usage results in large amounts of malware, penetration attempts, and security patches (the sheer number of WordPress installations makes it an attractive target for hackers).
• Community support for especially complicated problems will often run short.
• Professional service-level support may not be available.
• Usage of open source software may violate an organization’s IT policies.
• Open source software (not just CMSs) is heavily weighted toward the PHP and Java technology stacks.

We’ll discuss some of these points in greater depth in Acquiring a CMS.

Technology Stack

All software runs on a “stack” of supporting software, databases, and languages. A CMS is always implemented in a specific language and storage framework (which may or may not be “swappable”). This language and storage framework strongly influence what hosting environment the CMS needs to run.

The stack includes the following:

• The CMS itself
• A programming framework
• A programming language
• A database server
• A web Server
• An operating system

You can envision that as a pile of technologies, with the CMS sitting on top of it all and requiring everything below it to run properly.

This table shows an example stack comparison for two very different systems: Episerver and eZ Platform.

The crudest categorization of CMSs might be by technology stack. The most common stacks are:

• LAMP (Linux, Apache, MySQL, and PHP/Python/Perl; although almost always PHP)
• ASP.NET (Windows)
• Java/J2EE (Linux or Windows)

Less common stacks include:

• Ruby on Rails
• Python (usually the Django framework)
• Node.js

Systems cannot be swapped into different runtime languages, but hosting environments can vary slightly. For instance, while PHP normally runs on Apache and Linux, it can run reasonably well on Windows. ASP.NET almost always runs on Windows, but can sometimes run on Linux via the Mono framework.

This matters primarily if your organization limits the technology stacks it will support. While it would be ideal to select a CMS based solely on features and its fitness for your particular situation, the CMS still has to be installed and hosted somewhere. If your organization is hosting it, they might dictate all or parts of the stack. The same limitation applies if your organization is going to implement in-house – if your development group is full of Java programmers, then there’s a good chance you’re going to be limited to that stack.

It’s quite common for an IT department to only support specific combinations of technologies. Windows servers are a common requirement in corporate IT, as are specific database frameworks. Some companies dictate Oracle as their only officially supported database, while others might be more liberal. If these limitations exist in your organization, they will necessarily pare down the pool of possible CMSs you are able to implement.

The desirability of any particular stack is the subject of great debate and far beyond the scope of this book. The important point is that technology stack limitations – if they exist – are usually very rigid. If your organization dictates that only Windows servers can run in its data center, this is something you absolutely need to know before picking a CMS.

Management Versus Delivery

While almost everything a CMS does is lumped under the umbrella of “management” by default, the lifecycle of a piece of content can effectively be split at a hypothetical “Publish” button.

Everything that happens to content from the moment it’s created until the moment it dies is “management.” The subset of everything that happens to the published version of that content from the moment it’s published is “delivery.” The two disciplines are quite different.

Management is about security, control, and efficiency. It’s composed of functionalities like content modeling, permissions, versioning, and workflow. These are features that ease the creation of content, enable editorial collaboration, and keep content secure.

Delivery is about optimization and performance. The features involved in delivery depend highly on the capabilities of the CMS. These capabilities are currently evolving quickly in the marketplace. Until recently, delivery simply meant making content available at a public location. Today, the modern CMS is highly concerned with the performance and optimization of the content it delivers.

In the commercial space we’ve seen a plethora of tools that enable advanced marketing during delivery. Features like personalization, A/B testing, and analytics have proliferated as different vendors try to set their systems apart. These features used to be provided by separate “marketing automation” software packages that operated solely in the delivery environment. More and more, these tools are being built into the CMS.

The unintended result is that core management tools have changed little in the last half-decade. These tools have reached maturity in many cases, and the focus is currently clearly on marketing and optimization tools during delivery. Management is generally considered “good enough.”

Coupled Versus Decoupled

The “management vs. delivery” dichotomy manifests itself technically when considering the coupling level of a CMS. What hosting relationship does the management environment of a CMS have to the delivery environment?

In a coupled system, management and delivery occur on the same server (or farm of servers). Editors manage content on the same system where visitors consume it. Management and delivery are simply two sides of the same software.

This is an extremely common paradigm. Many developers and editors know of nothing else.

In a decoupled system, management and delivery are (wait for it) decoupled from one another. Content is managed in one environment (one server or farm) and then published to a separate environment (another server or farm). In these situations, the management functions are sometimes referred to as the “repository server,” and the delivery of the content takes place on a “publishing server” or “delivery server.” In these cases, published content is transported to an entirely separate environment, which may or may not have any knowledge of how the content was created or how it is managed.

Fewer and fewer systems support this paradigm, and it’s normally seen in high-availability or distributed publishing environments, such as when a website is delivered from multiple servers spread across multiple data centers (though this may be changing, as we’ll discuss at the end of the book). It has the perceived benefits of security, stability, and some editorial advantage, as editors can make large-scale changes to content without affecting the publishing environment, only to “push” all changes as a single batch when the content is ready (though this advantage is steadily finding its way into more and more coupled systems).

Actual technical benefits of decoupling include the ability to publish to multiple servers without the need to install the CMS on each (which lowers license fees, in the case of commercial CMSs), and the ability to publish to highly distributed environments (multiple data centers on multiple continents, for example). Additionally, the delivery environment could be running on an entirely different technology stack than the management environment, as some systems publish “inert” assets such as simple HTML files or database records, which have few environment restrictions.

The primary drawback to decoupling is that published content is separated from the repository, which makes “live” features like personalization and user-generated content more complicated. For example, accepting user comments is more difficult when those comments have to be transported “backward” from the delivery server to the repository server, and then the blog post on which they appear has to be republished (with the new comments displayed) “forward” to the delivery server.

To counter this, decoupled CMSs are moving toward publishing content directly into companion software running on the delivery servers that has some level of knowledge of the management CMS and can enable content delivery features. The result is a CMS that’s split in half, with management features running in one environment, and delivery features running in another.

Decoupled systems tend to be clustered on the Java technology stack. Some ASP.NET systems exist, but virtually no PHP systems use this paradigm.

We’ll discuss the differences between the two publishing models in Output and Publication Management.

Installed Versus Software-as-a-Service (SaaS)

More and more IT infrastructure is moving to “the cloud,” and CMSs are no different. While the norm used to be installation and configuration on your server infrastructure, vendors are now offering hosted or SaaS solutions more often. It’s not uncommon to have software rented from the vendor and hosted in its environment.

The benefit purports to be a CMS that is hosted and supported by the vendor that developed it. Whether or not this provides actual benefit is up for debate. For many, “hosted” or “SaaS” just means “someone else’s headache,” and there are multiple other ways to achieve this outside of the vendors themselves.

Closely related to the installed vs. SaaS debate is whether or not the CMS supports multiple, isolated users in the same environment. So-called “single-tenant” vs. “multitenant” systems are much like living in a house vs. an apartment building. Users of a multitenant system exist in the same shared runtime environment, isolated only by login. They occupy a crowded room, but each appears to be the only one there.

The purported benefit here is a “hands off” approach to technology. These systems are promoted as giving you instant access and allowing you to concentrate on your content, not on the technology running it. The trade-off is limits on your ability to customize, since you’re sharing the system with other clients.

We’ll discuss this dichotomy in greater detail in Acquiring a CMS.

Code Versus Content

The implementation of a CMS will almost always involve two types of programming code at some level. The system will have (1) customizations that are developed in the native code of the system (PHP, Java, or C#, for example), and (2) custom templating and the associated HTML, CSS, and JavaScript.

This code is usually managed in a source code management system such as Git or Team Foundation Server. It’s usually tested in a separate environment (a test or integration server) prior to launch. Launching new code is usually a scheduled event. Depending on your IT policy, new code might have to have approved test and change plans, as well as failure and backout plans in the event that something goes wrong.

With code under source control, there’s always “another place” where it lives. The CMS installation where it’s executing and providing value is not its home; it’s just deployed there for the moment. If that copy was ever destroyed for some reason, it could be redeployed from source control.

Content, on the other hand, is developed by editors and lives in the CMS. In coupled systems, it’s often developed in the production CMS and just kept unpublished until it’s ready to launch. It might be reviewed via a formal or informal workflow process, but often isn’t otherwise “tested.” If an editor has sufficient permissions, it’s possible to make a content change, review it, and publish it all within the span of a few minutes with no oversight.

Content will almost always change vastly more often than code. An organization might publish and modify content several dozen times a day, but only adjust the programming code behind the website every few months. When this happens, it’s to fix a bug or fundamentally change how something on the website functions, not simply to change the information presented to visitors.

Code and content are sometimes confused because of the legacy of static HTML websites. For an organization that built its website with static HTML, an HTML file had to be modified for a single word to change. Thus, a code change and a content change were the same thing.

Decoupled content management can also blur the line between code and content. In a decoupled system, modified content is often published to a test sandbox where it’s reviewed for accuracy, then published to the production environment. The existence of an entirely separate environment is similar to how code is managed. Content starts to act like code.

In these situations, it’s sometimes mentally hard to separate the test environment for content from the test environment for code. You have two different testing paradigms, each with its own environment, each pushing changes into the production environment.

This changes with a CMS, especially a coupled CMS. Under this paradigm, content changes without code changing at all. The verbiage of a press release might be completely rearranged, but the template that renders it is the same.

Organizations moving from static websites or decoupled systems sometimes have trouble adjusting to the idea of a “virtual” test/staging environment – unpublished content is created on the production server, and just not visible while it’s awaiting publication.

Their past correlation with code tempts them to treat content the same way and inter-mix the two concepts.

Code Versus Configuration

Many features in a CMS can be implemented through (1) developers writing code – either core code or templating code – or (2) editors and administrators working from the interface.

Developers have complete freedom, up to the limits of the system itself. There’s generally no functionality that is not available from code, as code itself is the core underpinning of the system. The only limitation on a developer is how well the API is architected to allow access and manipulation. But even with a poorly implemented API, a developer has the full capabilities of a programming language to get around shortcomings.

Editors, on the other hand, have access to only a subset of what a developer can do from code. They are limited to the functionality that has been exposed from the interface, which varies greatly depending on the system. Some systems allow minor configuration options to be set, while others have elaborate module and plug-in architectures that allow new functionality to be created from the interface on a running, production system.

Why wouldn’t a system expose all functionality from the interface? Sometimes it’s because a particular setting or piece of functionality is changed too infrequently to justify the effort of building an interface for it. Other times it’s because the person using it is more likely to be a developer who would like to change it from code, to ensure it gets versioned as source code and deployed like other code changes.

However, the most common reason is that the feature is simply too complicated to be managed by an interface. The ability to write code allows for the clear expression of extremely complex concepts. Developers are used to thinking abstractly about information and codifying it in code. Some features are simply too complex to easily build a management interface around them.

While building features from configuration sounds enticing, it can be a problem for management and maintenance. When editors are able to inject new modules and functionality in the production environment, this can make developing new code difficult for developers. Two groups are now developing the website together – one via code and one via configuration. The two groups are subject to different testing and deployment paradigms, and they might not be communicating about what they’re doing. Mysterious and sometimes catastrophic problems can result.

Uni- Versus Bidirectional Publishing

Some CMSs are like printed newspapers – they’re intended for a small group of editors to create and publish content to a large group of visitors who can’t directly respond. If an article in your local newspaper angers you over breakfast, there isn’t much you can do about it except throw your eggs, then write a letter to the editor that might get published weeks later.

Other CMSs are like town hall meetings – you are allowed and expected to participate. If a political candidate says something that annoys you, you can stand up, shake your fist, and yell your input directly into the conversation.

Before social media was a thing, and before user participation in websites was expected , most CMSs were very one-way. Editors published content that visitors consumed, blindly. Visitors didn’t have accounts on websites. They couldn’t create “profiles” or have “discussions.”

As one of my technical reviewers noted, “If user content showed up on your site, you had been hacked.”

Times have changed, and publishing can now go in both directions.

• Unidirectional (one-way) publishing means your organization is always pushing content “outward” to the consumer, often blindly (meaning the user is anonymous, and not logged in or otherwise identified).
• Bidirectional (two-way) publishing means the consumer can sometimes push content “backward” to the organization (by posting a comment, for instance).

Content coming back from the user is known as user-generated content (UGC). Some systems are designed for limited UGC, while others are built around it. Some might primarily be frameworks for managing UGC, more so than managing editor-created content.

This has all changed over the last decade, and such tools are common and expected these days. This means that older CMSs (those dating from the ‘90s) have had to backport this functionality, while newer CMSs have it built in.

Handling UGC requires some different tools than unidirectional publishing. If your CMS doesn’t provide these, then they need to be developed, or handled by other services (Disqus or Facebook for commenting, for instance).

Additionally, UGC blurs the line between editors and other users who can provide content – if visitors can create blogs on your site and publish blog posts, are they editors? What differentiates them from “real” editors, from inside your organization? If your entire website is built around UGC, then do you need a CMS, or do you really need a social network or a community-building tool? What about software that provides both?

UGC provides additional technical challenges for decoupled CMSs, as we discussed in the prior section. In effect, content can now be created from both directions, which makes concepts like the repository hard to isolate. In some cases, UGC like comments is actually stored directly in the delivery environment, rather than the repository, as it’s considered “lesser” content than that created by internal editors, and less likely to require editorial process or management.

There are several CMSs that position themselves in this space and promote feature-rich community tools. Other systems that don’t have these features are having to play catch-up, either tacking them on through extensions and add-on software, or integrating with other services.

Practicality Versus Elegance, and the Problem of Technical Debt

This final comparison isn’t specific to CMSs, but applies to software development in general. Still, it’s important to understand when discussing the context of the development of a CMS over time, and the implementation of your CMS specifically.

When considering new functionality, there’s a constant battle between (1) “just getting it done” and (2) taking a step back and rationally considering the best way to fit this functionality into the bigger picture. The former is faster and gets new features out the door, but the latter is more sustainable over time.

Just jamming new features into software creates what’s become known as https://en.wikipedia.org/wiki/Technical_debt[technical debt]. These are small problems and incompatibilities that accumulate over time. You pay “interest” on this debt in the form of workarounds, hacks, and extra work you have to do in the future to account for the poor choices made when the features were implemented. Eventually, you have to stop and “pay off” this debt by reimplementing the features, or the interest expense will crush you.

Extending our discussion about UGC from earlier, consider the need to add a commenting feature to an existing CMS. An eager developer might look at this and think, “Well, this is easy. I’ll just make a new system to handle comments, with its own storage and API calls, etc.”

This is a practical, quick solution. The developer might implement it in an afternoon.

However, somewhere down the road, suppose the editors get concerned about inflammatory comments, and decide they want the ability to hide certain comments. Okay, our intrepid developer says, that can be added.

Then, later, the editors want to go a step further and have the ability to edit comments. This brings up larger architectural issues of permissions and versioning. Our developer swallows hard, and declares that can also be added to the commenting system.

Finally, the editors have had it with flame wars in comment threads, and decide they want to implement full-blown workflow and approval on comments.

It’s at this point that our developer realizes that comments are content too, and perhaps they should have been implemented that way. It would have taken a little more work and thought, but the long-term sustainability and stability of the feature would have been improved. By treating comments as actual content – rather than a separate conceptual system – a lot of core functionality that the editors are asking for would be built in.

Now, this is just an illustration, and there are clearly situations where a separate commenting system might be appropriate. But the larger point is that sometimes the quick fix is not the right way to do something, and developing software is a constant battle between appeasing users who want something right now and making sure that they stay happy over the long term.

You can see this dichotomy in different CMS platforms. Some are a hacked together mishmash of programing paradigms and architectures, while others are well thought out and centrally planned to work in harmony long-term. The former develop quickly, while the latter are slower but more stable and easier to learn because there tend to be core principles and philosophies, with fewer exceptions and one-off workarounds.