Before we can tackle the question of to gem or not, we first have to understand what a gem is. That's not something that is totally easy to do, but we will take a high level look at it. Gems are bits of logic, in ruby, that can be "brought in" to do tasks. They are local copies of other projects. Rails it's self is just a compilation of gems. OTher languages have similar things. .Net has DLLs, Java has packages (or JARs), and python has modules. Just about every language used in production today has a method for "sharing logic" between other projects. That is the primary function of a gem. It lets your write a bit of logic one time, maintain it one time, and consume it in many projects. The best analogy that I can think of is your house's air conditioner. If your house was a rails project, the A/C would be a gem. It's an important part of your overall house, but they basically just come in and set the machine down, then "wire it up" with electrical and duct work. Yes it's integrated, and yest it's important, but your builder didn't have to build an air compressor, or air handler, or heat pump by hand from raw materials. He just caller Trane and plugged in their system.

Benifits of Gems

At it's core that's what a gem is. A chunk of logic that is not maintained as part of your project, but is instead included in your project as a functional part of the whole. The same with your house's air conditioner, if the heat pump breaks, your builder is not going to fix it, hes is going to call Trane to come fix it.

The primary advantage of gems is that your project can benefit from the popularity and complexity of the gem, without having to focus core development time on that part of the project. Take, for example Rails. Rails consists of 2,781 developers (as of now) that have actively contributed to the rails project. If you had to hire that many developers your budget would sky rocket.

Even if your parting out your project into a gem or gems, the primary benefit remains. When you consume your new gem in a second project, you save all the time you invested in that first project (and enhancements to the gem) from being applied to the second project. So if you spent 100 hours on Project A, then need Project B, but can use part of Project A as a gem, Project B's total cost goes down considerablely. Project A is at 100 hours, Project B would be at 100 hours, but with a gem; Project A is 100 hours, Project B is at 10 hours, and the Gem is at 10 hours. The overall cost of 120 hours is less then 200 hours so, gems start to make sense, even if there just internal.

Downsides to gems

That is not to say that there are not some downsides to gems. The gem it's self has a cost. It is not, usually, difficult to take the target logic from a project and make it a gem. That said, it could be. In our Project A and B example, if at some point you decided to abandon Project B and were no longer using the gem in multiple projects, then your total cost of development would be higher then keeping the logic directly in Project A.

In addition to that, there are, by it's nature, some constraints that apply to gems that do not apply to the same logic applied directly to a project. Namely, it's more difficult to write a good gem then to write the logic into Project A directly. Mostly, because the gem is designed to be used in many projects so it must be cleaner, tighter, and more focused then code that's in the project it's self. For example, a bug in Project A will only effect Project A, but a bug in the gem will effect Project A and Project B (along with any other projects using the gem).

Alternatives to gems

There is one alternative to gems that should be considered. Depending on how you want to consume your block of logic and what that logic does, you may write a separate application and expose/consume it's logic via API instead of including a gem.

For example lets say your a content site, you host a sub-domain with news, and one with reviews and anther with editorial pieces. All thee sub-domains are separate and individual. All three sites would like to start hosting video versions of their content. You could write a video upload and management gem, or you could write a fourth app, that handled videos and their concerns, and consume that video API in your three sites.

While the goal is basically the same as a gem, your have a different context that you can apply logic to. This may seem trivial, but take videos and the issue of copyrights. In the editorial site, and the news site, you may be the copyright holder. In the review site you may or may not be the copyright holder. Your "video app" can manage these situations better, and in a more centralized location, then the same set of management features in three different places.

Your news writers could write their news on the news site, and manage videos related to news. Your review writes could upload and manage review videos. Your copyright review team could then log into your video site and review all the videos for copyright issues from one central location.

Using a gem v.s. consuming an API comes down to a application and work-flow design question. There are pros and cons to each. You and your developer will need to talk about each option and choose the right path for your projects.

Back to the question! To gem or not to gem?

Once you understand what a gem is, what the benefits are, and what the risks are, the question becomes very simple. Do you have a bit of logic that is shared between two projects? Are those projects' life spans long term? Can you gain a better cost by sharing the logic between those two projects? If so, then gem. If not, then do not gem. Creating a gem from existing projects is easy, provided the projects are in good shape. So, it's almost always better to start with the logic in project, then refactor it out to a gem when your start your second project.

Coteyr.net Programming LLC. is about one thing. Getting your project done the way you like it. Using Agile development and management techniques, we are able to get even the most complex projects done in a short time frame and on a modest budget.

Feel free to contact me via any of the methods below. My normal hours are 10am to 10pm Eastern Standard Time. In case of emergency I am available 24/7.

Email: coteyr@coteyr.net
Phone: (813) 421-4338
GTalk: coteyr@coteyr.net
Skype: coteyr
Guru: Profile