Object-oriented programming (OOP) is all well and good for creating reusable, atomic components, more closely modeling the Real World with your code and all that. But as I come back to Java from non-OOP languages, I realize that it's also good at slowing me down just long enough to have to think about what I'm actually doing--and how it all fits together.
Yes, it's true that "Better is the enemy of done." Yet, the last time I checked, 50-90% of the cost of software was in the maintenance, not getting it out the door. In essence, focusing too much on "getting it out the door" creates a code debt. And like (nearly) all debt, it incurs interest. Every patch on or hack into a debtor program makes it that much harder to add the next patch or hack. (Lather, rinse, repeat.) That's the lesson that's woefully neglected in school, where one does not normally have to live with the consequences of one's design choices. Learning this lesson is not necessarily encouraged in the Real World, either, where far, far too many "prototype" or "demo" or "proof of concept" programs are somehow loosed upon real users and their real data.
That being said, there are times and places for just shoving code out the door. But I think that it would be a better world, from a software standpoint, if one of the "users" for whom we're programming is the poor schlub who has to fix or add to our code.
