I won’t claim to work for a big company, it’s still very much the opposite.  But over the past 5 or 6 years, I have seen a transition in how customers are marketed to and interacted with from sale to solution implementation and beyond.  We’ve gone from a group of 2 to a company of more than 70 complete with departments, budgets, vice presidents, BoDs, etc. 

I’m not a marketer so I’m not going to comment on our web presence or our quarterly e-mail campaigns.  They seem to be working as that mythical funnel remains full.  Needless to say, our sales process was very rudimentary back in the day, there certainly was no funnel.  We develop enterprise solutions and have always made the $100k+ deals.

All things aside, when you start considering customers as a number or percentage point in some quarterly metric you’re trying to hit, you’ve lost an edge.  The startup isn’t even going to have the metric in the first place, they’re going to be concentrating on getting the customer’s attention, getting them product, iterating on said product, and maintaining the relationship.  The product may suck (our first few releases definitely did) but that’s addressable over time.  The relationship is far more important and can be lost very quickly. 

The other thing that changes as a company gets larger is focus.  No longer do you have that laser guided focus on getting product to a single customer, you’re now dealing with existing and new customers simultaneously.  Your decision making ability slows as you’re forced to consider the implications of change to all customers.  It’s one of those annoying but necessary evils that comes with maturity and customer successes.  . 

I shouldn’t say it’s impossible to maintain the focus, it just becomes more difficult.  Your ability to focus on a particular customer is, in my mind, a key indicator of your ability to be successful.  It’s one of the reasons we track a customer satisfaction metric.  I won’t get into how it’s calculated, but essentially its a gauge of how often we’re communicating with a customer and whether or not the relationship is positive and if they’re happy with their particular solution.  Green is good, Red/Yellow is bad.

The other key indicator in my mind is not making the same mistake twice, but that’s a topic for another post.  It’s an item of significant competitive advantage that the slightly larger company has over the startup.

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. 

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!

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.

Particularly interesting for me was his overview of the different mechanisms by which you can support multiple customer schemas securely and with decent performance.  The product I’m actively working on is likely headed in this direction, looks like Oracle VPD is Emmanuel’s preferred solution.  A quick search has turned up an add-on for Postgres called Veil which aims to provide row/column-level security similar to Oracle VPD.  Good to at least have a choice, but I imagine that when push comes to shove, Oracle will win out.

Shards has always looked interesting, will be nice when it finally hits GA and supports the JPA API.  Would make it slightly easier to incorporate and play around with.

Interesting thoughts on clustering Lucene/Hibernate Search.  We’re currently running it asynchronously (ie. @Asynchronous in Seam) on a single node but will likely need to look at pushing it to a second box and trying to get indexes in near real time without noticeable degradation to the front-end.

It has not been a terrible experience (High-end dual-core with 8 gigs of ram does help) but I’ve been looking for more.

I’ve heard good things about Win7, and with the recent release of the RC, decided to upgrade.

I must say the process was quite painless and almost everything worked out of the box.  We just got a new SonicWALL Firewall/VPN at work and the client had to be re-installed.  Other than that, a minor tweak to the command-line parameters for Chrome and I was off to the races.

YMMV but I’ve seen a noticeable improvement in my day-to-day activities on the machine. 

I got an invitation today to join our pilot project on Google Apps for Enterprise.  Awesome, right!?

Is it bad than I’m looking forward to the opportunity to jettison all 35 or 40k emails and start anew?  I’d honestly trade that in an instance to free up the memory and CPU cycles chewed up by Entourage. 

It’ll be interesting to see how it plays out.  It’s still a pilot project so there are a few obvious and annoying gaps that force me back to Entourage, but if we can work out those kinks I’ll sure be a happy camper. 

Given that our executives were willing to jump on the iPhone bandwagon from the Blackberry, this idea could actually fly.

I’d be curious to hear from any small to mid-sized companies (we’re in the 75-100 employee range) that have made similar transitions.

That was on top of the better part of a day that was spent by another developer digging into the code.

Development ain’t easy, and frameworks for all their glory strive to make the easy stuff easier and the difficult stuff… well it’s still difficult.

Take Seam for example, a couple simple @In annotations here and there, and all of a sudden you have an application up and running. 

But throw transactions and exceptions into the mix and the expected behaviour is up in the air.

Imagine the following scenario:

Component A calls Component B.update() which in turn calls EntityManager.persist(someEntity).

someEntity fails a database constraint and an EntityAlreadyExists exception is propagated from Component B.update(). 

Can Component A turn around and update someEntity and call Component B.update() again?

It depends.  In Seam there is a RollbackInterceptor behind the scenes that will rollback any transaction crossing an injection boundary (it’s slightly more complicated than that but we’ll leave that for another day). 

If Component A was a POJO Transactional Seam component, and Component B was a Seam EntityHome component, this wouldn’t work.  In this sitation, Component B throwing an exception would actually rollback the transaction before control was returned to Component A.  Component A could very well handle the exception but the underlying transaction would still be rolled back.

From the looks of the implementation, the EntityHome (Component B) is relying on the entity existing in its PersistenceContext when doing an update.  You can update() multiple times as long as the transaction remains open and long-running.

Throw an exception into the mix and that transaction is likely to get rolled back by the RollbackInterceptor and the persistence context reset.

From that point on, calling Component B.update() (equivalent to EntityHome.update()) is going to report a success but do nothing but flush an empty persistence context. 

The short term fix was to have Component B.update() re-merge in someEntity.  However, rather than perverting the framework, it likely makes sense to dig deeper into the implementations and merge Component A and Component B to prevent the RollbackInterceptor from firing and rolling back the transaction on an exception that is recoverable.

The things you learn!

Few key points:

• Design for Intermediates Users
• Use Tools that Help Beginners to Become Intermediates
• Less is More
• Design for the Probable, Provide for the Possible
• Eliminate Errors or Confirmation Dialogs

There’s an interesting closing comment discussing the need (or lack there of) for error or confirmation dialogs. 

“Cooper notes that while they [error dialogs] are used to signal that something went wrong with the code, the user tends to interpret them as “I’ve done something wrong.”  When users are told that they are wrong repeatedly, they start to hate your product”

I suspect there’s some truth behind the statement, however all things being equal, if your product is blowing up, there’s a good chance that users aren’t going to be happy campers anyways.

That being said, I agree that showing an error dialog with some cryptic exception message only decipherable by the originating author, is probably not doing anyone a favor.  

Using the Java IDE IntelliJ as an example, it’s quite rare for a user to get an actual error dialog.  Instead, there’s a little status icon in the corner that will blink red whenever there’s a problem.  Clicking it will provide additional details with the option of submitting it back as a bug report. 

It’s important to remember who the user is, and considering the article’s focus on differentiating between beginner, intermediate and expert users, this status icon approach is probably best suited for intermediate/expert users, and not beginners. 

…

About 4 years ago, some friends and I decided to venture down to the neighborhood rib house for some an all-you-can-eat rib spectacle. 

It’s taken us awhile (years really, some even had to leave the country) to recover, but this time we’ll be 29 co-workers strong. 

The plan is to round everyone up and head to the saloon (yes, bonus points again because the place has saloon in it’s name) for a feast after work.  Should be a night to remember, everyone has been encouraged to wear a white shirt and make a mess of it. 

Food (and drink) is always a good bonding experience, so all-you-can-eat must be even better, right?

I’ll post an update after the fact, should have some better pictures this time as well.  If nothing else, ghetto iPhone photos will have to do us justice.