To gain a better understanding of why the one that's there is designed as it is. Sometimes there's legacy crap in the previous design thats no longer needed, or you have better materials, and can make the new one more elegant and functional. Sometimes it just gives you the opportunity to see all the failure modes that weren't obvious until you stuck your paper wheel in the place where a steel one had been.

This is one of the most common mistakes in software development: not appreciating that the true value of code is the knowledge embodied in it over time.

Ownership, chance to go back as consultant, chance to speak at conference.

Unless you are an architect or/and an old man/woman or/and don't enjoy programming, I don't see any reason you don't want to reinvent the wheels.

If reinventing the wheel implies no added benefit, the answer is never (or perhaps for educational reasons as someone else has suggested).

If you can identify a benefit, that needs to be weighed against the cost. A benefit may involve maintainability, flexibility, extendibility or any number of ibilities. But that is more like improving the wheel which is OK.

More control, different choices for tradeoffs, it's a decent way to get detailed knowledge, a reinvented wheel that only works for your specific company may be a better fit and simpler than a universal wheel.

Of course, there's plenty of ways to waste a lot of resources reinventing the wheel.

If you're doing clean room design: https://en.wikipedia.org/wiki/Clean_room_design then reinvention is allowed

I always say there’s only one rule you have to follow with respect to reinventing the wheel:

Do it on your time, don’t bring that shit to work.

You want a different/nicer wheel and the cost of reinventing it is low enough to make it worth it.

To learn