This reads like a vast oversimplification of types of Engineers and it paints certain design goals as "good" and "bad" .
Nonsense.
> However, an over-engineer can sometimes perform like an under-engineer or an engineer. Underperformance and overperformance could be influenced by a number of factors including work environment, context, intellectual horsepower, and even personal life.
I personally continue to write under-engineered and over-engineered code because there are so many internal and external factors that go into solving a problem.
For instance, last month this article[1] gave some seriously good insights to developer checkin frequency based on hard data. It provides a lot more value than the anecdotal, muddy definitions of over/under/engineer.
[1] - https://blog.gitprime.com/check-in-frequency-and-codebase-im...
That's a very interesting article. However, it does seem suffer from the same issues Joel outlined, namely, the measure of attributes of a commit can be gamed and worked towards to achieve a "prolific" or "senior" status.
What the article you linked does reinforce is the value of iterative development. As opposed to doing large infrequent commits, doing small bits of work more frequently causes a success higher or "impact".
I would say that the article provides a data driven approach to justifying the effectiveness of good iterative planning. However, it doesn't address whether the commits of the "senior" engineer or the "prolific" engineer are of high quality.
In saying that there certainly was some accuracy in my career between under engineering early on, then over engineering later. Nowadays I usually get a good balance (though it often depends how the problem is communicated).
For example, Linus Torvalds is an excellent engineer. So in the Linux kernel, he understood the trade off between modularity and simplicity/performance. That's why he did not choose microkernel architecture. He also understood that device drivers often require weird changes due to hardware evolution, that's why he decided against having too many abstraction layers in drivers (which would be better according to DRY rule).
Similarly, in Git, he decided not to use delta format to store changes. This takes more disk space (which is cheap today), but gives improved performance. Again, he understood the trade off, and concluded that performance is more valuable than disk space saved.