Makes sense - you can&#x27;t know the right abstraction upfront.<p>As Hejlsberg said:<p><i>&quot;If you ask beginning programmers to write a calendar control, they often think to themselves, &quot;Oh, I&#x27;m going to write the world&#x27;s best calendar control! It&#x27;s going to be polymorphic with respect to the kind of calendar. It will have displayers, and mungers, and this, that, and the other.&quot; They need to ship a calendar application in two months. They put all this infrastructure into place in the control, and then spend two days writing a crappy calendar application on top of it. They&#x27;ll think, &quot;In the next version of the application, I&#x27;m going to do so much more.&quot;<p>Once they start thinking about how they&#x27;re actually going to implement all of these other concretizations of their abstract design, however, it turns out that their design is completely wrong. And now they&#x27;ve painted themself into a corner, and they have to throw the whole thing out. I have seen that over and over. I&#x27;m a strong believer in being minimalistic. Unless you actually are going to solve the general problem, don&#x27;t try and put in place a framework for solving a specific one, because you don&#x27;t know what that framework should look like.&quot;</i><p><a href="http:&#x2F;&#x2F;www.artima.com&#x2F;intv&#x2F;handcuffsP.html" rel="nofollow">http:&#x2F;&#x2F;www.artima.com&#x2F;intv&#x2F;handcuffsP.html</a><p>So of course write it dirty, clean it up afterwards seems like a better idea, because it lets you feel what the right abstraction is. However it takes discipline to always refactor something that works fine already