Pronunciation: [ship uhv fee-see-uhs]
Definition:
A common flaw in enterprise-level software development, whereby continuity and back-compatibility is prioritized above all other concerns. This prioritization causes obsolete or poor choices made early in project development to hamstring future development. Common signs that you are working on a Ship of Feceus include reinventing the wheel in ways that make no sense without historical context, or completely eschewing evolving standards among your peers, in favor of an “incremental solution”. Incremental changes are certainly preferred over breaking changes, and not all back-compatible changes are a Ship of Feceus, but often times a large change either requires many smaller, user-invisible refactorings to be released first, to prepare for the eventual change, or it requires a single breaking change to do the job right.
Variations: The Grandfather’s Ass, Rebuilding the Shit-to Shrine
Related Terms: Technical Debt, Spaghetti Code, Defactoring, Not Invented Here
Notable Examples:
- Microsoft Windows 10 cannot support filepaths longer than 256 characters in length, due to decisions made in Windows 95 and contractual obligations to their Windows API users
- Facebook designed their own PHP compiler, called HipHop, to avoid refactoring their codebase as they scaled beyond the capabilities of the PHP language. They have since created their own formal variant of PHP, called HACK, to add modern typing and other missing features to the PHP language.
- Twitter pushed their initial codebase as far as it could go, dealing with common outages due to a poorly structured initial codebase. In June of 2009, they finally shut down the site for a one-day maintenance window, relaunching the service on a completely rewritten codebase. Outages vanished overnight.
- WordPress’s proposed Gutenberg editor stores structured content as a mix of HTML comments and semantic tags, in an attempt to provide complete back compatibility to older versions of their editor.
Common Solutions:
- Componentize your codebase, so you can support both the previous version and new version of your code, side-by-side. This requires building or refactoring for Dependency Isolation.
- Provide an upgrade path for users, using an automated data conversion process, where possible.
- Provide legacy-oriented helper functions for third-party developers, so they can support the new codebase with minimal changes.
- Provide a slow, well-documented path for rollout, so developers and users have time to adapt.
- Provide LTS releases, so users who cannot make the shift will still be supported in their current workflow.