Since I have time, I'll do it right, with a factory class, and extendible configuration package (that I'll write myself so it will be just perfect) and, for optimal speed, I'll use Red-Black trees that I'll have to write my own implementation of since there isn't a standard library ...
What's wrong with separation of concerns, extendability, optimal speed, etc.?
More often than not, I observed doing it right the first time is actually a huge time saver compared to hacking some stupid prototype nobody can understand later.
Agreed, except in cases where the code will never be maintained again (e.g. game releases on N64). In my experience an "over-estimate" that leads to the so called "do it right" syndrome happens if someone else estimates for a developer. When the developer makes the estimate him/herself and doubles it, you can be damn sure they are going to need all that time and then some to even get it in the ballpark of long-term acceptable.
(That being said, the company needs to have standards for code acceptability in the first place, which doesn't always happen)
You are saying I'm wrong because good engineering is better that writing crap. Except that's not what I said; I was saying over-engineering is bad and we should stick to engineering.
Since I have time, I'll do it right, with a factory class, and extendible configuration package (that I'll write myself so it will be just perfect) and, for optimal speed, I'll use Red-Black trees that I'll have to write my own implementation of since there isn't a standard library ...