A fool trap is always hidden. It shows up only when fully "mature", or when an advised programmer is able to recognize it during its early phases of birth. Or when you realize you're stuck in it.

It's a piece of code that doesn't fit directly in your project's goals. It can be a "tool" that you design, something you may want to use for helping you develop code, or do things "better", or "faster". It can also be a feature that the end-user will actually perceive or use.

The problem is, a fool trap is always "on the edge of working", but it really never works. Or, you always have only that little thing to add for it to be perfect, never having the opportunity to claim OK, now it's over. You often get obsessed by your fool trap, on how easy it should be to finally make it work, and jump to the real work.

At the end, you look back and say "Man! How did I manage to spend 2 full days over the last weeks on this thing??"

* ''2 days? It ain't a fooltrap until you have wasted 2 weeks over the course of several months tinkering with the damn thing.''

How do you recognize a fool trap?

* It's not directly related to your project's goal.
* It's always "almost done".
* Takes an abnormal amount of time to develop (and burns this time from your time bank).

-- DaveLacerte

----
CategoryAntiPattern