Monday, July 21, 2008

There is no such thing as "functionally complete"

I just completed revisions to our Software Development Methodology handbook. It got me thinking about how many times I have written something like this and how its changed over the years.

As would be expected from a Software as a Service company, we approach things from an incremental development and update perspective.

We look to deliver new features every 6 to 8 weeks. We have a product roadmap which is a living and breathing organism. At the beginning of each year, we sit down (representatives from Marketing, Client Services and R and D are all there).
We look at the Roadmap and work out what is needed for the following year.
Once we satisfy this objective we then proceed to work out what is needed in the first 6 to 8 week iteration. As we release each cycle, we review the roadmap and determine the requirements for the following cycle.

This is the reasoning for my post title. At no point do we ever say our product/service is functionally complete. Back in the days of on premise software, we would pursue the venerable Waterfall approach. We would map out and plan for a development project of 12 to 18 months, aiming for at most 1 release per year. Users wouldn't even get close to the new version until it was close to being "functionally complete" as a product. I would remember our customers/prospects getting all excited by some great new feature we would show them in a presentation, but a year is a long time in business, and by the time the product update was officially released, all the positive "vibes" and excitement of the initial announcements would have truly been forgotten.

By having 6 to 8 week feature updates, we are continually registering small wins with our customer and prospect base and keeping strong the goodwill of those customers. It also makes the term "functionally complete" an anachronism. A service should always be evolving and adapting. If you wait for 12 to 18 months between releases, your product will die a slow death.

Tuesday, July 1, 2008

Google building Business Apps

I read a very interesting post by software engineer Sergey Solyanik who tells his story of leaving Microsoft, going to work for Google and returning to Microsoft.


Its a balanced account of the reasons why he returned to Microsoft, What caught my eye and got me thinking was his opinions on the challenges Google has in building solutions targeted at business. Google along with its primary search products has built a series of popular "free" products. By being "free", Google enables its development teams to be more "agile" and release code to production environments frequently, however accordingly there seem to be fairly frequent introductions of new bugs and outages but by being "Free", the user base is also more accepting of these issues.

This would appear to be a major inhibitor to Business market dominance. As Google begins entering the business market, the dynamics totally change. You have to build apps which are an integral part of running a business, not just "free" nice to haves, otherwise you will need never get widespread adoptance. Businesses by their very nature are far less forgiving of problems and as such would prefer to pay to ensure adequate quality,reliability and support are in place for any products they choose to use in their business.

Technical Support for business with SLAs in place does not currently exist at Google.
This got me thinking about the Salesforce.com/Google Apps colloboration. This is a pretty smart move by Google. I have to think this would benefit Google more than Salesforce.com though. Google partners with a company with huge credibility in the business world and they also get to leverage the infrastructure for training and support of customers that Salesforce.com have in place. In a way, Google is outsourcing these functions to Salesforce.com.

This is all good for customers who are using Salesforce.com and Google Apps, but what about the others who don't use Salesforce.com but want to use Google Apps with agreed upon SLA's and support?

Its my guess though that Google is not going to setup huge Support and Client Service Departments, I think they will continue with outsourcing this part of the business and utilizing business partners.

Salesforce.com Data Centers are also more focused on running business apps with high percentage uptimes and SLA's in place. I am not sure how Google's distributed server farms will handle business applications at guaranteed Service levels.

Google are certainly big enough to make it in the Business Market, but its not going to be a quick win.