Patterns Schmatterns: But Don’t Forget the Fun
Courtesy of SeanMonstar, I now know to guard myself against Criminal Overengineering.
The most insidious cause of overengineering is over-generalizing. We will over-generalize anything given half a chance. Writing code to work with a list of students? Well, we might want to work with teachers and the general public someday, better add a base People class and subclass Student from that. Or Person and then EducationPerson and then Student. Yes, that’s better, right?
…
We have to stop championing each ridiculous feat of overengineering and call it what it is. It’s not ‘future-proof’, because we can’t see the future. It’s not robust, it’s hard to read. Applying a generic solution to a single case isn’t good programming, it’s criminal overengineering because like it or not somebody, somewhere will pay for it.
He mentions fear as a motivator; the worry that your code won’t stand up against the unforeseen use-case. He also describes the sense of productivity it engenders. In other words, “look at all this code I just cranked out”.
And while I agree with everything he says, I do have a small point of contention: He doesn’t account for the fun factor. This must be the exception to the rule. The one time it is okay to shoot way high.
I mean, isn’t it fun to create these beasts? To take a simple problem and abstract it out to this giant chain of inheritance and interfaces and abstractions? I’m serious here. I’m sure there exist the coders who enjoy nothing more than filling in a function stub with one return statement, mumbling “done” to themselves, and then moving on to the next task at hand. But aren’t most of us the kind who enjoy the creating and building of these…things?
So yeah, while absorbing the fluorescent rays of a cubicle sun, make sure not to “makes things harder than they are” (to quote my dad) too often. But try to find an excuse every now and again to exercise those creative muscles and think larger than the simple problem at hand. That’s what I say.