Make sure not to “too” future-proof your code
When doing a bit of code review, I saw an incredibly ornately architected future-proof module written by one of my programmers on my team. It had taken him roughly 3x as long as I had estimated, but the code was very complete. It was created in such a way that every single portion of it was modular and could be interchanged quite easily.
However, remember, it did take him 3x as long as we estimated.
If you work on timelines, you know that a project that takes 3x as long is not a success, no matter how great the code is. So, I started up the conversation with him asking about the reasons he made certain choices. Turns out, he had thought of almost every single future way to use this code and implemented architecture to support that. He covered instances where we might change our database, our models, even our front controller and consumption patterns.
While this is fine and dandy, I would say that he went too far with future proofing. And here’s why…
In the programming world, current tech moves so fast. We have to be constantly churning out new code to keep up with all the new features and technologies. This presents a difficult balance that we must consider. We need to create code that is able to be re-used when the dependency technologies change, but at the same time, need to hit deadlines for our current requirements. I would also submit that sometimes planning for technology interchange wastes current time so that by the time we finish, that technology we planned for is already out of date.
Now, don’t get me wrong. I’m not saying we shouldn’t future proof our code and keep it modular, but it has to be a balance. Get working code out the door that has the basic architecture to be modular. Each individual method doesn’t need to be interchangeable 100%.
Let me give an example. Say, there are three social networks out there that do music related communities for your music website: MySpace, MusicEar, and defNotes (I think I made up the last two). The requirements are to build a unified login system with a music website, preferably MySpace, for the music site you’re creating. You have three options:
- Cater to just MySpace
- Build a pluggable system for any network, then build a MySpace plugin
- Build a system with a basic framework to allow plugable items, but hard code in the MySpace dependency
Obviously, you now know my desire would be #3. Because, by the time you finished #2, MusicEar and defNotes may be out of business. And #1 doesn’t allow much flexibility for future networks that you don’t know about yet.
So, how would one do that? That’s where the balance comes in. But, I can think of some ways. Say, when you want to create a new instance of the social network class, call a factory method. This first iteration, all it does is return new MySpace(). In the future, if you implement a new network, you can then modify that factory method to return the proper class.
The balance comes from honestly assessing what the future may look like. Look at your client and customer base. What is the likelihood of that customer base using the other methods? If its not very high, don’t future-program for it.
3 comments on “Make sure not to “too” future-proof your code”-
Brandon Savage says:
March 30, 2013 at 7:16 am
Reply
-
Aaron says:
March 30, 2013 at 9:43 am
Reply
-
Mark Skowron says:
April 8, 2013 at 12:05 pm
Reply
The purpose of object oriented programming is to create modular, reusable code. It’s not to think through every possible use of your code in the future. The modular nature of object oriented programming already accounts for this, which is the protection offered by object oriented programming.
Your developer would have been better off creating interfaces for their classes, and typehinting on the interfaces where dependencies were required. Then, he wouldn’t have had to think through cases where you’d change the database or the models, because the interfaces should and would allow for that with little to no fuss.
But in no circumstances is it better to hard code a returned object (e.g. new Myspace()) That’s untestable, and requires far more code changes when you implement a new option. Dependency injection is a far better practice to undertake, and doesn’t take any extra time.
Great feedback Brandon. I fear that my point may not be as clear as it needs to be based on your comment, however.
The point is really this: Yes, its great to program the best OO scenario possible, but at some point we have to be ok with stub methods being there. For example, lets say the social network module was created by our main class with a factory method. In the first iteration, I know I only support ‘MySpace()’ – so I can simply make the factory return a new instance of that. The next iteration, if there is one, is when the programming gets completed for where to store all the additional modules, how the “magic” is performed to figure out which ones to instantiate, etc.
Like I said, you are right – but at some point, you have to balance the amount of time spent creating proper/perfect code and architecture with the amount of time available for a project. Now, that isn’t to say I wouldn’t preach ‘perfection’ if I was giving a presentation about OO coding in PHP – but in the real world of timelines and estimations, it is important to stay on task. I’d rather see a hybrid going to the right solution, than the right solution days late, or the wrong solution entirely.
Thanks for the feedback!
I agree entirely with your article. This applies to front-end development as well. It’s important to define the scope of the project and stay within your time estimate and budget, even if that means cutting out some extra features — that while cool — might take extra time to implement. Just because you CAN add all the bells and whistles doesn’t mean the client is paying for them. However, making your code standards-based is something that should never be compromised.