In a post last week, I talked about various problem spaces that exist in WordPress, but I also briefly touched on the idea of practical applications as it relates to writing WordPress-specific solutions.
Specifically, I made the comment (more or less in passing):
When I was in school, I had to take a class in Computational Theory. For the most part, I’m more of a fan of practical application, but I know that much of said practical applications are the concrete implementations of proven theories.
And then I went on to talk about more theoretical topics as it relates to solving problems in a given computing space (for us, that’d be WordPress).
Since I spoke about the previous topic at this particular level, I thought it might be fun talk about a more accurate or more practical approach to writing WordPress-specific software.
Recently, I’ve been working on a codebase that’s a few years old. The desire to want to refactor the whole codebase is strong (and I know I’m not alone in feeling this way when it comes to working with previous projects).
But this is not pragmatic, and it’s not so for some different reasons. So over the next three posts, I thought I’d share a little bit about the state of the project, managing the tension that exists, and how to do what we can when we’re faced with this type of situation.
