Hm. That's another of those sage pieces of advice that gets quoted far too often, and nearly always out of a correct context.

Debugging and maintenance are quite different things. Although the latter can involve some of the former, it first starts by breaking working code in order to adapt it to new requirements. That is, you do not normally enter maintenance mode until a "working state" has been achieved.

This becomes particularly significant when the working state is achieved at or close to the limits of what is possible--as with many of TheDamian's modules. They rely for the possibility of their operation on being closely coupled to the (internal) features and even quirks of the Perl. As such, they become susceptible not only to breakage through internals changes, but also to the 'fixing' of quirks. More significantly, they require deep understanding of those internals--and how they change over time--for their initial possibility and their continued operation. Unless the maintenance programmer fully grasps their modes of operation in their original form; plus all the internal changes and how they affect the operation; they are hard pressed to be able to keep them working as the internals evolve over time.

There is also a difference between 'clever' for it's own sake; and 'clever' of necessity. When pushing the boundaries of possibility, it is often necessary to clever. The alternative is to achieve nothing.