Skip to content.

Personal tools
You are here: Home » Members » chrism's Home » The Curse of Allowing People to Succeed Poorly

The Curse of Allowing People to Succeed Poorly

The punishment for allowing people to succeed poorly? Death.

People hate systems that allow them to succeed poorly. They hate such systems even more than systems that don't allow them to succeed at all. People will forgive systems that don't allow them to succeed; they will never forgive a system that allowed them to succeed poorly.

This is because, by allowing a person to succeed poorly, you have tricked them into believing a problem is solved and that they may move on to the next problem. The problem, however, is not solved. The problem remains, papered over by something that only makes it appear solved. Because the problem was not solved, the implementor will eventually need to revisit the problem. Except now instead of just having one problem to solve, he'll have two: he'll have to re-solve the original problem, then he'll have to figure out how to make the code that implemented the previous (poor) solution work on top of new code for backwards compatibility purposes.

It's hard enough to solve a problem in "green-fields" coding; needing to carry along the burden of backwards compatibility with older code and possibly rebasing old code on top of the new solution makes it at least twice as hard. Sometimes ten times as hard.

This is why people hate software that allows them to succeed poorly. It makes 2-10 times as much work for them in the long run. It would be far better if the software they chose either a) allowed them to succeed optimally or b) allowed them to fail very quickly.

The very most potent vitriol is reserved for systems which allow people to succeed poorly. Consider the hatred unleashed on public forums, even today, ten years later for Zope 2 features like TTW coding, large-ZODB-objects-as-blobs and implicit acquisition. All of these technologies provided solutions (albeit not full ones) for real problems at the time and they became widely used. Each one of these things allowed people to do things that were previously very difficult with very little effort. But ultimately, solutions based on these systems needed to be revisited due to performance problems, testability, and code comprehension. All have been largely sunsetted, because it was recognized that the development effort required to allow people to truly succeed when using them would be enormous.

But still, people actively hate them and will go out of their way to tell others so (usually in a brutal form like "Zope sucks"). Ten years later. Do you see vitriol like this for technologies that people failed entirely with? No. This is because these people felt fooled and betrayed in the long run.

What's the takeaway? If you're going to introduce a feature to code that other people rely on, start by documenting it. If you cannot document it adequately, or you find that you may need to spend an inordinate amount of time creating code that makes the feature not suck, don't add the feature. Only add the feature when you can both document the feature itself and its failure modes. Be conservative about what you offer. You can always add features; you can never take them away. If you do add a feature, make sure that it doesn't pretend to do more than it actually does. Allow its common usage to have a "fail quickly" path.

Created by chrism
Last modified 2010-01-29 11:50 AM