I understand the point you are making, but would like to add one more discussion point (which detracts a bit from your point but I think is still valid).
Sometimes a developer implements the bare necessary required solution to the problem, i.e. not an over engineered expensive solution.
We'll then state that his solution was poorly engineered and he wasn't a good developer, but it's not fair to look at his solution in hindsight and judge it by the amount of scope creep it could handle(which it obviously had to handle in hindsight).
Your succesor might write here in some time that your solution, while being appropriate for json, didn't use x technique and so couldn't handle XML input, and had you only known about x...
(This isn't critique of your comment, which I found insightful and positive, just one more factor to consider)
I inherited some Python scripts that pulled data from various sources and assembled web pages to present a coherent view of all of the data.
These scripts were very brittle, and slightly malformed data could cause them to fail entirely.
After about a year of maintaining these old scripts, one of the data sources got replaced with a shiny new database system, requiring a major rewrite to the scripts. So I just started over from scratch. Having seen the problems running and maintaining the old ones, I made numerous better design decisions, resulting in far more robust scripts, which are (I think) much more easily maintained.
But indeed, my predecessor was no fool. His scripts likely grew and grew and grew until they were a pile of hard to maintain code. I doubt that he himself would have advocated their design, but he just didn't find time / value toward rewriting them. I only rewrote them because I was forced to.
And I'm sure that my future successor could improve upon what I've done. For that matter, I myself could improve upon what I've done, but hey, it works well enough, and I'd be better off spending time on other things...
Sometimes a developer implements the bare necessary required solution to the problem, i.e. not an over engineered expensive solution.
We'll then state that his solution was poorly engineered and he wasn't a good developer, but it's not fair to look at his solution in hindsight and judge it by the amount of scope creep it could handle(which it obviously had to handle in hindsight).
Your succesor might write here in some time that your solution, while being appropriate for json, didn't use x technique and so couldn't handle XML input, and had you only known about x...
(This isn't critique of your comment, which I found insightful and positive, just one more factor to consider)