Often times we’re forced to make sacrifices, but when is it the right time to push back or accept defeat?

Obviously what follows here are my own opinions but I’m a firm believer that a well executed plan only 80% complete, is worth leaps and bounds more than a flawed plan 100% complete.

A few questions I commonly ask myself:

• Is what I’m working on tied to a software release.  We release on a month basis in two 2 week iterations.  I know that if I want to make it into a release, I need to have it done sufficiently ahead of time in order to ensure adequate testing.  This may mean cutting scope.  Cutting scope is fine IMO, just do so in a way that you avoid silly shortcuts that create headaches for yourself when you inevitably have to come back and add functionality.
• Who is the consumer. Is it a paying customer (ie. they have already paid)? Is it for a demo? Is it for another developer? If its a customer, what are they actually trying to accomplish? Often times, we get caught up in our own expectations of how something should look or behave, and lose sight of what the customer is actually trying to do.  If the customer is currently using pen & paper to track something, a simple (ugly?) web form may be perfectly acceptable. Don’t overcomplify. With good feedback, you can always come back and do a better job. Focus on the present, don’t get distracted on what you *might* need to do in the future.
• How often is the functionality used. If the feature or function being worked on is used by a handful of backend administrators, you may not need to go over the top on day one.  If they come back and tell you that they absolutely cannot use the system without A, B or C.  Make sure you understand what A, B and C are and get cracking.  Quick turnaround built loyalty and trust.  You need both as early in the customer relationship as possible.  If the feature is public facing and used by a large percentage of the audience, by all means, perfect it.
• Do I need to modify the database. From a technical perspective, this has always been a killer.  Make a flub manipulating the database, and you’ll cause yourself countless hours of time trying to correct customer datasets. Get representational datasets, migrate them automatically and test test test!  Speaking from experience, do not cut corners testing or working with your database migrations.
• Have I been burnt in this area before. Maybe the work you’re doing is in direct response to a filed bug.  Either way, if you’re working a particularly risky area of the codebase, it’s worth going that extra step to ensure you’ve got solid code coverage (unit, regression, selenium tests, etc.).  Fool me once… Fool me twice…

There are plenty more, but in general, I err on the side of trying to get releases out the door.  If we spend 20 calendar days in a release (4 work weeks), up to 6 of those will be spent either performing non-automated regression tests (don’t worry, we have automated tests as well) or fixing post code-complete deficiencies. 

Test cases are a given.  If you’re working Java or any other programming language with tooling like JUnit or TestNG, I really see no excuse not to use it.  If nothing else, it’s a good safety net if you ever need to refactor a particular area of the code base. 

If I had to pick a guiding principle, it would be:  Get it in, Make it right, Make it fast. 

Get it in because you need the feedback.

Make it right because that’s what we’re paid to do and stakeholders expect it.

Make it fast because it’s no fun staying up until 2:00am trying to debug performance problems on a customers live system.

The trivial case worked.

@XmlRootElement
public class ExtMessage
{
    private String owner;

    @XmlElement
    private ExtConcreteBody body;

}

What I set about doing next caused some immediate grief.  My intention for ‘body’ is to actually be one of many JSON entities. First attempt was to introduce a JSONBody interface and use that instead of ExtConcreteBody.

@XmlRootElement
public class ExtMessage
{
    private String owner;

    @XmlElement
    private JSONBody body;

}

Of course that didn’t work.  At marshalling time, the JAXB provider complained about not supporting interfaces.

A quick search on Google said I wasn’t the only person who had run into this problem before. 

Best resource I found was the JAXB User Guide.  Seems to have some funny rendering and be slightly out of date, but it led me down the correct path.

Essentially you need to make use of an XmlJavaTypeAdapter.  JAXB ships a default one (AnyTypeAdapter) that will generate a ‘type="xs:anyType"’ in your xml schema.  If you want specific type support, you can implement your own Adapter. 

After adding the class-level @XmlJavaTypeAdapter(AnyTypeAdapter.class) to JSONBody, I thought I had it licked.

Then the JAXB provider complained that “Marshalling Error: class [...] nor any of its super class is known to this context”.

WTF?

Fortunately that led me to a comment on a random blog post on Collections and JAX-RS mentioning that you should use an @XmlSeeAlso(…) if you want to avoid that error.

Finally it works.

@XmlRootElement

@XmlSeeAlso(ExtConcreteBody.class)
public class ExtMessage
{
    private String owner;

    @XmlElement
    private JSONBody body;

}

@XmlJavaTypeAdapter(AnyTypeAdapter.class)
public interface JSONBody
{
}

@XmlRootElement
public class ExtConreteBody implements JSONBody
{
    private int id;

}

The JSON looked like:

{"extMessage":{"body":{"@type":"extConcreateBody","id":"0"},"owner":"dummy.user"}}

Which seemed reasonable to me.

Hopefully this helps anyone else out there that is having grief trying to do the same thing!

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!