It was all a lie

As I embark on my next project that will require me to duplicate efforts that I know have already been made, I think back to one of the initial promises of OO: reusable objects. When I first started learning about OO many moons ago I was told that there would be this wonderful and vast trove of objects that I could simply pick up, augment and reuse for my own purposes. The unfortunate reality is that there are a precious few objects available.

But why is this?

Off the top of my head a few reasons come to mind.

  • Licensing. I have worked in what could be considered to be the “staff augmentation” business for quite some time. All this that boils down to is I typically have very little say or sway when it comes to licensing potentially useful technology. Compounding that is the much feared GPL. Companies run shrieking away from GPL’d software.
  • Language constraints. A number of widely used programming languages are severely limited in their ability to augment existing objects. For example, in Java I cannot add a new member to Object that would then be present in all objects. (In theory I actually can do this with AOP but the JVM goes out of its way to make this a nightmare.)
  • YAGNI. The whole religion of “you aren’t gonna need it” mandates that the objects you create should only have the functionality that they need. By not providing those “well, maybe” hooks, these objects are limiting their own lifetimes and usefulness.
  • Lack of imagination. The ability for a developer to think out of their domain is severely limited (and is only going to get worse as each domain becomes more complex). This will limit the potential usefulness of produced objects to other domains.
  • Different standards. Different frameworks, different approaches, etc all contribute to objects that are fundamentally incompatible.

This entry was not written to bring about change or to criticize but only to point out some of the road blocks that exist.

Continue reading It was all a lie — Part 2.



  1. The YAGNI principal is something I’ve struggled with for a long time. It seems countless projects have failed because developers chose to ‘purchase the option’ to include functionality that may be used sometime in the future. Typically before that happens the project is canceled due to the additional time spent on this extra functionality instead of the core functionality required to make it a success. In theory refactoring should allow the YAGNI principal to exist as this additional functionality can be added over time and as needed instead of purchasing the option to include it initially while putting the current scope at risk. Of course, common sense is never a bad thing when trying to build reusable components/objects while predicting future needs. 🙂

  2. Your observations are certainly consistent within the scope of a project. My entry was looking at YAGNI from an external (i.e. pick up someone elses objects) perspective. For example, I’m not going to pick up JBoss and start refactoring it. The barrier of entry just to use it is high enough much less attempting to perturbate it. On top of that, attempting to integrate resolved defects after the perturbation is a nightmare.
    Thank you for your comments!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s