the Future of Work

As a developer: I can build it but should I?

by Danny Kolke
published on: 01/22/08 11:31:30 AM

In a conversation yesterday, we were discussing a new partner that is starting to use various services from Etelos in their application. As we went through the issues, we kept coming back to the same statement, "We can build that."

Granted, right now with the tools available and the speed at which new tools are becoming available you probably can build every application that you could conceivably need in your business. But should you?

How do you look at technology and decide as a developer, should I build this feature myself or should I utilize someone else? Build or Buy, maybe better known as "BOB," is a question that all companies face. But developers of Web-based applications are facing this dilemma more than ever.

Reasons to Build

There are reasons today why I think building is a correct decision:

1. Limitation: If the limits of a current solution are going to constrain your business growth and success you must consider the building option. But then a major question is: what do you build it on? 
2. Integration: How significant is the solution in the overall experience that you need to provide in your business model? Many times, simple integration solves a critical business process. Tight integration, may require total ownership of the solution.
3. Quality Control: If you are properly resourced with your staff, and this application is in a critical area of control; then maybe you should build it. But don't confuse things that are commodities and necessary, with critical, i.e. payment processing, first level support, etc. These are critical, but should you build them or can you simply integrate an existing tool or service easily?
4. Budget: Generally speaking, I use budget as a reason not to build. But, if you have the budget to afford to build the solution that is critical to #1-#3 then you should consider it, as long as you can afford #5.
5. Time: For many, time is the biggest issue that affects the decision. Do you have enough time to do it yourself? Even if you have the talent, the resources, and the budget, can you afford the amount of time it will take to build it, test it, revise it, build again, test it again, etc. Depending on the complexity of the solution and the project, this can be a very forbidding task and the time required doesn't match the time allotted.

Summing all of these up, I come to the conclusion that the answer is where the accountability lies in your business model. If your competitive value proposition is in delivering X, then maybe it's essential that you build it. But don't confuse "best practices" with "competitive value" propositions, ie. your billing system must be accurate -- but is that the competitive value proposition?

Reasons NOT to Build

Then there are reasons why I think making someone else build it makes more sense:

1. Passion, or lack thereof: You aren't passionate about this area of your business so why invest any mental capacity into it? To develop something that will be a great application, you really need to be passionate about it.
2. Expertise and resources: You lack the expertise and resources to deal with the problem or to staff a solution in these areas could be detrimental to your business model. Do you really want to have an expert in every area? Even if it's critical, it often makes little sense.
3. Commoditization: Everyone is doing it and doing it cheaper than ever before. When the whole world is in that space, why do you want to be there?
4. Time Cost: The time to build vs. implement is disproportionately expensive. Every minute of every day is spent; avoid the cost of investing time in new areas that could be spent elsewhere.
5. Opportunity Cost: What is the opportunity cost if you build it (i.e. what are you not doing because you are building your own)? 
6. Best Practice Partnerships: When you can get best practices implemented in your solution through partnerships and still gain competitive advantage in the areas of expertise and passion you do have, this is the best reason of all not to build. Utilize a partner that is going to commit to solving problems that you can build on top of. I call it "best practices" because both you and the partner are adhering to an agreed standard that helps ensure quality and free you to excel where you can.

What is a Best Practice Partner?

As an example, should you be figuring out how to scale the database, or should you be implementing best practices solutions that enable your hosting provider to scale? Do you write an e-commerce, user management system, or do you adhere to open standards and best practices that enable you and your partners to scale?

Done right, you excel. Done wrong and you end up on your own. And what you just spent was opportunity cost.

Don Campbell (Etelos, VP of Strategic Development) says, "I like to build cool stuff. Engineers like to build cool stuff. But sometimes an app gets so much momentum and a community of developers, how can you compete with it? I'm thinking of apps like WordPress, with hundreds of plug-ins and theme developers all making the App great. In that case, you're better off extending something like that than trying to build your own."

I think the biggest reason not to build is time. As a human being, you only have so many minutes in a day and assuming that you have better things to do like kiss the wife and play with kids; you don't want to spend your like rebuilding sewers and water supplies. Shoot, I have a Kubota with a backhoe and I love digging ditches with it, but I'd rather play my 1939 Steinway Model B than re-plumb the neighborhood's water system.  

I know this sounds absurd, but when it comes to resource planning with your business, there is a lot of truth to applying these principles. Should you really be investing your time on things that don't directly enable you to increase sales or competitive advantage? 

Don has more to say, "...still, for some companies, a highly specialized tool is needed, and it is then worth it to build your own. Especially since the tools now, as mentioned above, allow people to build things very quickly."

Reasons Etelos Builds

At Etelos, we constantly battle the question of building something new vs. integration. And it's not an easy choice all the time. There is a litmus test that we use to decide.

1- What is our mission?
2- What is our passion? 
3- What do we provide?

We integrate far more tools than we build. Let me make that an absolute statement. Proof? That's why with Version 6 of the Etelos Application Server^TM we are supporting porting LAMP applications and why we added support for MySQL, etc. That's why with Version 5, we added support for JSP and C#/.Net.

We use Apache, Postfix, PostgreSQL, and support Python, wxPython and more. Not to mention the popular buzz around JSON, AJAX, REST, RPC blah blah blah ... With all the great technologies out there, our mission is to provide a place to bring them together.

What do we build? Mostly we build tools that bring these things together. We build bridging technologies that enable a PHP app and a Java app to run in the same account and synchronize data easily. We build things that enable non-SaaS apps to become distributed on-demand as if it was engineered for SaaS all along.

Lots more on this topic, and this post is now at the dangerously long stage.

More on this next time.