Jon Pretty

Had to work with some code I wrote a few years ago where I went maximally polymorphic for the hell of it - it was just as painful as when working with badly documented and poorly tested dynamically checked code.

This might be true, but you probably have to revisit such code less frequently, and have less of it.

Not sure which code you mean. I do have less maximally polymorphic code than just plain bad code. My argument is not against maximal polymorphism, but against unnecessary maximal polymorphism. Why abstract over something that is always going to be concrete?

Because often the cost of developing the polymorphic version isn't high. When you write the concrete version, and you discover you need similar functionality again, you have a choice between generalizing the first one & updating its call site and writing a new concrete version.

Both of those are less desirable than simply using the polymorphic version you wrote the first time. That's not to say premature generalization is always a good idea: it certainly isn't. But it's not a universal truth that you should do the minimal that solves today's problem.

It really has to be a balancing act: how reusable can you make the first implementation? How likely is it that you'll need it? How difficult is it? How opaque will the implementation be?