Don't Fall in Love With Your Own Code!

Professional sports teams have always puzzled me. Anecdotally, it always seems that teams constantly over value their own players. A minor league player is going to be the next big thing, we can’t part with him, he’s the future etc etc.. And in the end it just doesn't pan out, the player gets traded elsewhere, fails there, then fades into the sunset. In some cases, it’s just the fact that it’s really really hard to evaluate who will make it, and who will not. But I’m absolutely sure that in some cases, it’s a GM or scout that falls in love with his player, and refuses to see the flaws in that player.

Ok enough about sports. How does this relate to your project and problems?

It’s clear to me, that some organizations and some people fall in love with their own code, and this includes myself.

You see I had written a neat little micro services framework for my current project, it was all cloud aware and had an embedded servlet engine based on Jetty and Oauth security built into it, it used Jersey for REST API. It allowed you to define your data objects in a neat way and the framework would persist them, serialize them, move them to a shared memory etc etc etc. It could run on the cloud, it could be clustered, nodes could communicate easily between each other, it managed service lifecycles etc etc. I used as much open source components to make all of this work as I could, but there was a lot of my own “secret” sauce, I was really proud of it.

And then came a very very dark day.

I like to keep myself up to date on the latest and greatest things, and it Greater Toronto area, I've found quite a few tech Meetup’s where the presentations are quite relevant to what I do. I often learn quite a lot in these presentations.

So on this particular day, I found myself learning about something called “Spring Boot” (http://projects.spring.io/spring-boot/). Very early in the presentation, I had a horrific realization.. These spring boot guys were trying to solve the very same problems that I was. Spring Boot was pretty much the same as my own home grown framework!

Now earlier on in my career, I would have looked at all the great ideas in Spring Boot, and then “copied” them into my framework. Certainly my work is better, my framework is lighter, faster, easier to use.. Right?

So what do I do now?

I had visions of the entire company using my home grown framework, it was mine, I was going to be a hero! I was in the process of preparing documentation on how to use it, maven repositories so that other developers could import it into their projects. Maybe the company would open source my framework, I’d be known as a community leader, I’d be quasi famous!

As so often happens in life, if you’re really honest with yourself, reality always rears it’s ugly head. There’s one prevailing fact that makes it almost impossible to not at least evaluate Spring Boot.

• Every single line of code in your code base costs your company money! Both to create and to maintain.

So is framework/library better than our own home-grown solution?

This really isn't about my framework vs. Spring Boot. This is about any home grown code vs. something that you can obtain, either by purchasing, or via open source.

So what are the criteria we need to evaluate?

• Quality of the framework / library.
• Community surrounding the framework / library.
• Cost of converting your code.
• Is your home grown code arguably better?

Quality

Is the code used by lot’s of projects? Are there unit tests? What does to code look like? Does the design seem to make sense?  

Community

Is there a community surrounding the project? Are there companies supporting it? Does the community seem “stable”? Does the project seem to have “vision” and a roadmap? Can you choose to purchase support?

Cost

What is the cost of converting to the framework? Does your team have the skills? How much training is necessary? What is the cost of keeping the code you have vs. changing. By the way, there is a cost to using a pre-existing library, nothing comes free. You still need to test against it, contribute to the community, possibly enhance it etc etc.. Evaluating a library for use is beyond the scope of this article.

Is Yours Better?

Sometimes a framework like Spring tries to be all things to all people and does nothing particularly well. I’m not saying that’s true of Spring Boot, from my experience Spring Boot is a well thought out microservices framework. But your own home grown project may be tailored to your exact need, and may actually be better for your company.

Actually if yours is better, you might consider contributing to the framework / library if you can to bring it up to your needs. It may prove to be less costly than maintaining your code.

So what did I do?

To be honest, I haven’t really decided what to do. We are currently close to release, and obviously, changing now is not an option. But as I plan towards the technology for the next version of our product, I will definitely fully evaluate using the criteria above, in fact I will evaluate all of the work we did for 1.0 and see if we can improve it with different open source libraries. As always, I’m hoping that our architecture plans for the next version will be driven by clear customer use cases!

A bootnote

Although I don’t really focus on open source in this article. If your company uses any these libraries, you should also try to find ways to contribute. There’s a lot of good business sense for this, such as:

• Your contributions will help make the library/framework better (hopefully)
• You can maybe have some influence on the library/framework
• The library/framework would not exist without someones contribution.