| I propose a new term: Consultancy Driven Development. It goes like this: - If it's too easy to set up, nobody will hire us to make it work. - Implement a kickass setup dirt cheap for some big-name company, so we can claim they use it in production. Yeah we tweaked it so it bears little resemblance to the original product, and only fits an incredibly narrow use case, but nobody stands to benefit from blogging about that. - Better ship with a configuration file that isn't production ready. - Did I say one? Better have three configuration files, each duplicated in distribution-dependent directories (in some cases), needing manual sync between servers to prevent catastrophic data loss. - Remember not to publish the program that checks for errors in configuration; half of our income would disappear. - Benchmark with a configuration file that nobody would use in production, but looks really impressive when taken out of context. - People want transactions, remember to claim support (and if you must, explain somewhere in the fine print that a transaction can only span a single operation on exactly one document, and btw. is precisely none of A, C, I or D). - Somewhere on the front page, it should say how we can support petabytes of data (and it performs very well, as long as you write all your data in one batch, never modify it, keep it all in memory, and turn off persistence). - Never give away answers online. Answer every question about configuration with "it depends". - Don't release a new version without renaming a few configuration options. Be "backwards compatible" by ignoring unknown, obsolete and misspelled options. |
* Extremely difficult to set up.
* Claims that half of Fortune 100 uses it (read: many are required to support it; the rest have one guy with a toy installation in some branch office).
* Consists of dozens of components, each with several-thousand lines config files (actually Python code) that must be kept in sync between all nodes (yet have node-specific data).
* Claims to be "modular", but have complex interdependencies between each of the components.
* Upgrading is not officially supported, but some companies will help you.
* Will break in mysterious ways, and require you to backport bugfixes since you're stuck on an unsupported version after a year.
* Have unhelpful error messages (e.g. throw Connection Refused exception when you're actually receiving an unexpected HTTP return code).
* Write documentation in a way that appears OK to new users, but vague enough to be useless for those who are looking for specific information.