Nothing Was Delivered

A while ago, I saw a blog post from an experienced programmer lament that younger guys use Object Oriented Programming for everything because, well, that’s how they’re taught now. Often that makes sense, he explained, but sometimes you just want a quick script to do a task and be done with it. What the younger programmer could do in 20 lines of code this guy could do in 10 by getting rid of the object boilerplate. 

I haven’t been doing this long enough to form any habits, but I do have some scripts that I’ve been using for a while at work. They mostly do one thing, They’re not pretty, but they work. 

Then, I found myself wishing one of them did something else too. Or maybe instead of. Maybe I could add a small flag to change a behavior. That seems like it’s within my skill set. 

Except, since it is just a 100 line procedural script, there’s really no way to break it out into base parts and change its behavior under certain circumstances. So I basically started tearing the script apart and putting it back together as a class, which I can then add methods to and call as I need. It’s not only that this will let me get my desired outcome today, but that this will make it (kinda) easier on me down the road, when I get further grandiose ideas. 

The lesson here isn’t, I think, that one should always use OOP (or Functional Programming, if that’s your bag) for everything. The lesson is to think about the future, even with something small. If you’re writing a script that you expect to keep using down the road, try to future proof it as much as you can. Your needs will change over time, and that’s okay.