Being a custom development shop—or at least a shop that completes the majority of our projects with custom solutions—we often find ourselves debating the merits of off-the-shelf CMSs versus custom software. In fact, I wrote a rather lengthy article about this particular debate just a few weeks ago.
One of the major arguments we hear in favor of off-the-shelf software is portability. Often, if a prospect or customer is wary of the idea of custom software, they will cite the fact that since off-the-shelf software is ubiquitous across the industry, it should be easy for future designers or developers to take over the project if ever needed.
I understand the argument and the thinking behind it because it serves as a hedge against the gamble you make whenever you hire a development team. But is this really true? Are off-the-shelf platforms easier to port from one developer to another?
The answer—much like every other technological debate that can be had—is yes and no.
In a way, sure, off-the-shelf platforms have a layer of commonality that make it somewhat easier to transition versus their custom-built cousins. However, much like any other piece of infrastructure that is built and requires maintenance, there are many things that can affect off-the-shelf software and its ability to be ported from one developer (or host, for that matter) to another.
In this post, we’re going to take a look at experiences we’ve had transitioning clients from other development teams and list of some of the principal reasons I believe the alleged quick and easy portability of off-the-shelf platforms is one of the larger misconceptions in our industry today.
By the way, before I get into our points below—I know some of the more technically minded readers are going to call me out on the other definition of “code portability.” They would be right, in fact, to point out that the term most often applies to the ability of coded applications to work across multiple operating systems.
For the purposes of this article, I’m referring to it as platform and code portability, mostly because there simply isn’t a better term out there to describe the scenario at hand.
With that said, onto our post: What are some factors that can affect the portability of your future project?
Development Style
Many web developers consider themselves artists rather than technicians. Artisans, not engineers. And as with any artistic endeavor, you have the variable of style, which is a concept that carries over to web experience design and development.
Now, I’m most definitely not an expert in terms of art history, nor am I a regular connoisseur of fine arts. But I can see the differences between Pollack and Van Gogh and the differences between impressionism and cubism. The same differences in style and technique exist in software as well. A developer’s personality and organizational tendencies carry over to their coding and implementation techniques. An organized and efficient coder may utilize a different coding methodology or habits than someone who is, for lack of a better term, a bit scattered.
This concept makes coding and platform portability difficult, a challenge where potential issues and roadblocks can’t be predicted. It’s rare that you see a total stylistic match from one development team to another.
Ever transition from one developer to another? Did the new team have anything nice to say about the previous one? That’s because when it comes to coding and implementation styles, few developers rarely agree about the best or most elegant ways to complete a task.
While this problem exists with both custom and off-the-shelf software, I believe it is actually heightened with off-the-shelf software.
One reason is that developers and “themers” are different people. A true web developer—or someone who can build custom software—is adept at writing, editing, and managing actual code. Themers are individuals who are adept at installing a piece of software and extending it by installing more software on top of it.
With WordPress, for example, this type of technician is all too common. Installing the base platform and then installing and configuring plugins is not complicated. However, this is completely unlike actually coding. As such, these individuals may be reliant on installing plugin after plugin even when a more elegant solution is possible.
On the other hand, developers may make changes to the actual source code of the off-the-shelf platform or build on top of it, adding complexity. In this scenario, transitioning from a hardcore developer can be also challenging, as you’ll have to dig deep to find out what’s really going on under the hood.
This is where you, the client, is most affected. Developers, for the most part, work in units of time, where time equals money. Learning what previous developers have done to make a platform work can add up to serious bucks during a transition. Whether moving from a themer or a developer, you could have a quagmire of issues transitioning your off-the-shelf software.
Where custom software differs in terms of style is that the style differential can be a bit less severe—custom software developers diverge at a much smaller scale than themers or customizers. A quality LAMP developer can recognize PHP code and work through its behavior rather quickly, especially if the previous team commented the code as they developed the project. They may not agree with the exact implementation or the methodology used, but conceptually, they can handle what they find without too much trouble.
Skill & Ability
Above I referred to style, or preferences developers have for completing the tasks they set out to accomplish. However, we shouldn’t deny that ability and experience will determine the breadth of possibilities regarding those preferences.
It’s important to know that the choices available to a developer vary greatly based on their experience and capability. The biggest problem with being a customer or client is the difficulty of determining a development team’s abilities relative to other teams, or in terms of your specific project.
There is no magic formula for determining the ability level of your developer if you have limited development experience yourself. The best recommendation we can make is to spend more time reviewing past projects and experiences that the developer lists in their portfolio. Vet them properly by contacting old customers and asking detailed questions about the quality of their work. Sure, the references won’t know the quality of the coding in many respects, but they can shed light on the development process, any roadblocks encountered, and how the project has stood the test of time.
Projects with low ongoing maintenance costs, easy-to-perform updates, and longevity are a great indicator about the quality of a developer or development team.
Project Specific Complexity
Sometimes, code or platform portability is made difficult by the specific functionalities or performance requirements of your project. If the goal is to have a platform you can easily move from one developer to another (in the case of a relationship shift or even onboarding your own team), then it’s important to carefully architect the solution with this scenario in mind.
It’s not uncommon when we onboard new clients to run into a variety of “gotcha” scenarios within their software platform that make the transition into a nightmare. While I hate broad generalizations, easy code portability with complex, customized off-the-shelf applications is more myth than reality.
The truth is, skeletons in the closet typically exist, having been created innocently enough to help the off-the-shelf software accomplish specific goals at the time of development.
Unfortunately, it can result in a plethora of potential pitfalls down the road.
What can you do to ensure you have an easier transition if you must make a move? In my opinion, control over the ecosystem is the number one way you can avoid frustrations and truly hedge your bet.
Never let a company host your solution on their own servers or infrastructure. If you are moving, it’ll be for a variety of reasons, but typically, your current provider won’t be happy to see you go. Avoid the awkward and often painful transition period that exists by ensuring from day one that you hold all the keys to a building you own.
Avoiding having to transition software with many moving parts from one place to another will make code portability much more realistic. In fact, it redefines portability from being the ability to relocate and reconfigure an entire property to simply the ability to transition to another team—two tasks that, when done at the same time, can be frustrating to execute.
Age & Technical Debt
Platform and code portability, in many instances, is determined not just by the complexity of the software and how it was made, but also by how it was evolved and maintained.
As we explored in a post two weeks ago, technical debt is an overlooked variable that exists with all software, regardless of whether it’s off-the-shelf or custom-developed. The problem is when technical debt gets out of control, when fixes upon fixes result in a snowball effect with the result being massive instability.
The prevalence of technical debt is astonishing. Almost all of the well-known off-the-shelf platforms are inundated with technical debt from the moment you install it. And over time, the mish-mash of plugins, themes, updates, and extensions or enhancements to your software installation can make the platform incapable of being portable at all.
In fact, this is why it seems like you are redeveloping your CMS every couple of years or so.
One of the many benefits of custom software is that those developing and maintaining the platform can closely monitor the severity of technical debt. Off-the-shelf software, as I mentioned, can be affected by technical debt in two ways: the initial platform itself and the customizations you’ve made to it.
In this way, software taken off the shelf—whether licensed or open-source—are, in reality, less portable than their custom-built counterparts.
Conclusion
When hiring a web development team or freelance developer, it’s important to hedge your bets to ensure that you are protected. However, it isn’t always the wisest long-term move to think you can guarantee yourself a safety net because you chose one platform without first determining if the platform is the perfect fit for your situation or not.
The fact that the WordPress developer community is large isn’t necessarily a good thing—the larger the community, the better your chances are of finding help that isn’t actually capable of accomplishing your goals.
In choosing a development platform, focus more on the problem itself and how the platforms you are considering solve that problem in the best possible way, as opposed to focusing on tertiary concerns, such as how you’ll manage to transition the platform in the future from one place to another.
