I’ve been away for a crazy couple of weeks, but a lot has happened. In the last couple of weeks, the stars have aligned and a lot of CTO events have happened in Southern California and I have had the fortune to attend several of those.

The common thread when socializing with CTO’s the conversation is, naturally, revolving around the Stack. Every CTO starts the conversation with that because its the common ground to the badge of honor that holds the recipe for making the company unique. In this fast paced world, and with a limited set of resources, I keep finding myself quite often using existing services and just focusing on integration a lot more then creation. I have made the conscious decision of, whenever possible, I will gamble on focusing on the operation of the business than crafting software that may not create any strategic advantage….Whew, that was a lot of buzzwords, in short I mean that:

My strategy is to focus on building the experience rather than building software that I am not in the business of creating.

This may seem unappealing to some engineers as we, engineers, tend to be very DIY but in the long run, there will be less tech hoarding. And in the long run, you can also use the resource of smart developers to create bigger and more important things not just to reinvent the wheel. So then under this principle, when to buy and when to build?

Build vs Buy

  • Does it exist?
  • How much does it do of the things I’d like to do?
  • Are the things I can’t do a total deal breaker? (For example, things I need to create a competitive advantage)
  • Are the core things that I am expecting done in a reasonable manner?
  • Can I integrate with other services (does it have an API, and how complete is it)?
  • What are the restrictions in Licensing?

If you get a pass in all these elements, I will vote for buying or using (in the case of Open Source projects).

The Buzzword frameworks

Another thing I have noticed lately, is that a lot of times whoever architects the software ends up choosing frameworks because they are a fancy toy that they would like to play with.

A perfect example is node.js. Javascript, while it is a little nifty language and even though the runtimes are super fast, lets keep in mind that it was created in 10 days and to this day a lot of issues are still around that may make your code less readable and therefore a coding nightmare.

I am well aware that a lot of silly nuances and code readability is improved through coffee script and that in some cases you do want to take advantage of asynchronous processing but I tend to prefer to do that kind of stuff for the front end rather than for a backend. For more in-depth a more detailed explanation of pros, cons and extra info. Check out this great article by Tomislav on why and how to use node.