Kevin P. Taylor

Why Build Custom Software?

In Code rant: Why is 'Buy' not always better than 'Build', Mike Hadlow opens his blog post by stating that "Building software is hard." He goes on to describe how this fact eventually leads most organizations to ponder the universal question: Should we buy or build our next software system?

As Hadlow explains, commercial off-the-shelf (COTS) software is often a great choice for common business needs, such as word processing. I would go a bit further and say that COTS software is a viable choice for any business need that isn't, and shouldn't be, a competitive advantage for your organization.

What does that mean? Well, if your accounting system is unique to your organization, watch out. Worst case, your system may not follow GAAP accounting principles. More likely, it is simply not very effective software and doesn't follow industry best practices. This will be true for many business functions, such as call-center management, document management, and email marketing. Chances are slim that there are any ways your company can gain a competitive advantage by building its own software for any of these common business needs.

But, what if the software system in question provides functionality that you consider a competitive advantage? For instance, if you run a large head-hunting firm should you use a COTS system for finding, tracking, and managing your candidates and clients? If you are large and successful, the way your staff finds, tracks, and manages candidates and clients should be a competitive advantage. Why would you give up that advantage by moving to a COTS system that your competitors can also purchase?

If a COTS solution is better than your current solution for a business function that should be one of your competitive advantages, you need to rethink, and possibly re-engineer, how your company performs that function. For instance, a large e-commerce organization should have plenty of competitive advantages built into its warehousing, customer-service, on-line shopping, and vendor management systems. If not, they may be in trouble.

Buying versus building makes sense in many cases. But, without even considering the hidden costs of customizing and integrating COTS systems (which Hadlow covers nicely), it is often the case that building a custom software solution is the only choice that makes strategic business sense.

Blogging From TypePad Mobile

If you are a TypePad user, I recommend downloading their mobile client. I am using it on my Treo 700p, to a limited extent.

The mobile blogging client allows you to create new posts, edit existing draft posts, and upload and attach images from your Treo's camera. This last feature is particularly nice with the Treo 700p's built in 1 mega-pixel camera.

So far my only frustration is the seeming lack of support for markup in blog text. For instance, the link to TypePad above was inserted by editing this post via TypePad's Web interface after I first created and published the post directly from the mobile client.

Adding Tasks to Google Apps

One piece of functionality that is painfully missing from Google Apps is task tracking and sharing. Fortunately, Remember the Milk provides straightforward task tracking and sharing and it has seamless integration with Google Calendar.

According to their site, they have both a free and a paid premium plan. I am trying out the free plan now to see how stable it is. My main concern will be that the service has minimal downtime during business hours and low latency.

One very nice feature is the email integration. Each user is given a custom email "inbox". You can create new tasks by sending an email to your inbox. Better, you can use codes at the beginning of the email body to set attributes on the task.

For instance, you could send an email to your task inbox with the following email subject line and codes in the email body:

Subject: Friday's Task
L: Obtiva
P: 2
E: 1 hour
D: Friday
---
This is a note for my Friday task.

This creates a task named "Friday's Task", adds it to the Obtiva task list, gives it a medium priority (2), an estimate of 1 hour, and a due date of Friday. Also, there is a note attached to the task, "This is a note for my Friday task."

Evolving the Simplest Tools that Will Work

Our company, Obtiva, is an Agile software development company. But, Agile principles permeate all aspects of Obtiva and go well beyond our software projects. We are an Agile Business. As such, one of the core Agile values that we strive for in our business operations is simplicity.

Simplicity manifests itself in many forms during our daily routines while running business operations. The use of lightweight tools is one obvious example. For instance, we leverage Google Apps extensively for email, collaborative documents, and a shared calendar. In most cases, a new business tool begins life as a Google spreadsheet.

Over time (days or months) those spreadsheets and shared documents become less and less effective. The spreadsheet may have only been conceived of as a business logic prototype. Or, a particularly useful spreadsheet may offer significant business value, and the promise of much greater value, if it only had x (feel free to name x).

At this point, we have a choice: invest time and money in an off-the-shelf tool that we can customize to some extent or build our own one-size-fits-one tool. Using Ruby on Rails and other lightweight technologies, we are surprisingly often able to spend only hours to convert a spreadsheet into a Web-based business application.

Even better, our one-size-fits-one applications start life with only the smallest kernel of high priority features, maximizing ROI. Over time, we can continue to add features, of course, as our business needs evolve. We are not locked into any particular vendor's feature set (not enough, too many, or the wrong mix) nor are we at their mercy for bug fixes or upgrades.

First, view you initial application needs through a minimalist's eyes (What is the simplest thing that will work?). Second, leverage the flexibility and productivity of tools like Google Apps, Ruby and Ruby on Rails to deliver just the right level of functionality vs cost.

Bye, Bye 600. Hello 700p!

Unbelievably, my Treo 600 is still functional. It has survived my abuse since I received it as a gift for Christmas back in 2004.

But, it's finally time to send the old 600 off to live on a big farm in the country. And, it's time to say hi to my new Treo 700p. 1.3 mega-pixel camera with digital zoom, video capture, EvDO, streaming TV, a crisp speaker, bluetooth. Wow.

As a consultant, getting a consistent Internet connection is always an issue. This hack allows me to use the 700p as a high-speed modem with my MacBookPro. I can live with consistent connection speeds over 230K while on the road.

Mobile life is good for Mac OS X users.