There are moments in software development when ordinary or common usage of an API, library, language or tool won't solve a programming problem.
At such times, some programmers retreat and consider alternative solutions that rely on simple, ordinary code. Other programmers refuse to give up and push forward to find whatever uncommon or arcane parts of the API, library, language or tool will yield a solution.
Producing a solution that relies on non-ordinary or arcane parts of other code is a sign that you may be muscling your design.
After muscling it, lesser programmers are often proud of their handiwork.
"Look at how brilliant I am! While mere mortals would have given up, I found a way to write this code using sophisticated, seldom-used techniques."
A Muscled Design
Ten years ago, a colleague and I programmed Industrial Logic's services catalog.
We were using Java, XML and XSLT to transform our company's training/coaching catalog into HTML.
I had a good deal of XSLT experience from previous client work and knew that the best way to work with XSLT was to keep it simple.
I explained that to my colleague who had less experience than me.
I said "if we ever have to dig really deep into the XSLT documentation to figure out how to do something hard, chances are there is an easier way to get it done by simply producing XML that is easier to transform."
He agreed.
At the time, I was traveling a fair bit, so my colleague had some solo programming time.
When I got back from one trip, he had managed to dig very deep into the XSLT library to find a way to format dates so that they looked pretty in our catalog.
The resulting XSLT was hard to read and used some arcane XSLT techniques that were buried in the XSLT documentation.
As I studied the solution, it was abundantly clear that he could have performed the date formatting logic quite easily in Java, output that formatted date as XML and then used simple XSLT to transform it into HTML.
Such Java code would not have been hard to write and it would have resulted in simple, ordinary Java, XML and XLST.
Instead we had a complicated XSLT routine.
Whenever possible, avoid muscling a design by considering ways to solve the problem using simple, ordinary code.