07 Sep 2009
Background
The company I work for made the decision to OEM a product from a partner, rather than invest valuable development time to build something that has essentially been commoditized.
Development resources are at a premium and we consciously don’t want to spend any more time on this code base than we have to, we’re much better at adding value in other areas.
Not necessarily a bad or the wrong decision, we’ve just reached the point in time where we need to make functional changes to the OEM’d code base.
Due Diligence
Obviously, before you entertain the outright purchase or license of a third party product/code base, there’s a few questions you ought to ask yourself:
*– Is the technology stack compatible with our existing products? *(A member of the development staff should provide the answer)
–* Does the product do significantly less/more than we will ever need it to? *(The later is an important question, do you really want to maintain features that customers will never use? What’s the cost of re-implementing just the features the customer does need?)
– *What’s the support model look like? *(Who is fixing bugs, you or the source company? How are patches exchanged, or are they?)
Maintenance
During the course of our due diligence, we did send a couple developers on site to become familiar with not only the code base but in particular the build process around it.
This did pay dividends as we were able to setup Bamboo builds capable of automatically creating installation packages and running unit tests.
Significant win in my books. Test coverage may not be the greatest, but if you can build a complete candidate release in 7 minutes, manual testing/verification remains a possibility.
That’s it for now.
I’ll admit that I was a skeptic when the idea of adopting a 3rd party code base was first brought up. Fortunately the changes we’ve been required to make thus far have been minor. Technology stack is slightly different and anecdotally bug fixes seem to be taking ~3x longer then they would on our primary product, I expect that ratio to more or less even out as we familiarize ourselves with the patterns and structure in the new code base.
The verdict’s still out on whether or not we’ll be able to add any new components of significant functionality while keeping things at all maintainable.
But of course that’s the challenge inherent with any software development activity!
07 Sep 2009
I must admit that I’ve been a terrible blogger these past few months.
I blame Twitter!
Now that fall is upon us, I’m going to try and write more than 140 characters on a somewhat regular basis.
08 Jul 2009
The team and I have recently kicked off a rather ambitious project. In an attempt to help accelerate the early development activities, we’ve made a decision to build a series of one-off implementations using the DeveloperForce.com platform (salesforce.com sans the sales CRM portions).
The objective is to learn enough about the platform during these initial largely custom implementations, to be in a position to hopefully create and deliver a largely standalone solutions faster than we would using the typical Java technology stack.
The jury is still out, but what follows are some initial thoughts after working with the platform. The team in question are a group of 3 senior developers working collectively on an application deployed in a single Salesforce Organization. **
Forgive my use or miss-use of Salesforce/DeveloperForce terminology. *It can get confusing at times 
*
Version Control
Like any good development shop, we store all code and build artifacts in source control. Subversion is our poison of choice.
Salesforce development is a bit different in that a lot of the configuration and development activities can occur in either the browser or their Eclipse-based IDE.
Our strategy for getting code and configurations under source control was to use Eclipse and regularly sync with our development organizations (Salesforce jargon for a development space or area).
Unbeknownst to us at the onset, there are certain configurations you can make using the browser that are not possible to make with the IDE. It’s important that these configurations (user/queue creation, etc.) are documented externally (ie. in a spreadsheet).
Code and configurations are moved between developers using Subversion and the Eclipse synchronization capabilities (or the Salesforce migration tool). By storing these artifacts in Subversion, we’re also able to do code reviews on them via Crucible.
Your mileage may vary with this approach, as we found the current Salesforce tooling to be quite poor at conflict resolution when it came to structural changes. Moreover, we frequently had to fall back to manually making changes via the web browser. ****
Very annoying.
I think it’s safe to assume that despite all the redeeming qualities of the DeveloperForce platform, some significant gaps remain when it comes to the expectations of traditional software developers. By traditional, I mean those of us that are used to using source control, doing code reviews, etc. I guess Salesforce considers us a dying breed
Would I choose the platform to build a product I expected to maintain in the long-term and derive significant value from? No.
Would I use it in the short-term as a RAD environment to build a prototype? Possibly, but not without first considering some of the more traditional alternatives (there are a number of schema-less data storage products available these days, combine that with a Grails, Seam, Rails or Django and you may very well be off to the races).
That’s enough for one night. I plan on doing a follow-up once the team has more experience maintaining and migrating code after it’s been deployed to DeveloperForce.