I am generally a fan of the rule of three, yet there is definitely some validity to your point. It takes experience and judgment to know when to abstract and wh

I am generally a fan of the rule of three, yet there is definitely some validity to your point. It takes experience and judgment to know when to abstract and when not to. If you happen to have a narrow domain where you have solved the same problems repeatedly in the past, it's often easy to see the right abstraction. In a new domain with new problems, and unclear requirements, it's much harder. Of course, from this distance it's impossible for someone to judge whether your or your management's judgment is warranted. But there is a risk in junking it, called the "Second System Effect". Don't over abstract this time. Also, it's also worthwhile to document and explicitly write out a list of requirements. You can be more or less scientific about this, but the exercise will keep you focused on meeting requirements instead of ivory tower design.