But what if there's a broader, more realistic view of the changing FileMaker Pro world that reverses this attitude? A view in which the needs of self-preservation suggest not competition, but cooperation? Suppose a powerful way for in-house developers to thrive in their positions is to learn how to use consultants wisely? I believe this view makes more sense than the first one; read on to find out why.

Slippery terms

From the outset, it's necessary to clear up some confusion. In a DevCon workshop in 2007, I pointed out that these terms "in-house" and "consultant," as applied to developers, are slippery. They invite confusion. All that "in-house" denotes is someone who builds FileMaker Pro software for his own employer. Similarly, "consultant" defines those who build software for companies other than their own. In terms of definitions, therefore, of hard, stable meaning we can use in technical conversations -- all we've got is employment status.

The trouble comes because, as a community, that isn't what we're interested in. Employment status has nothing in and of itself to do with building software. And it is building software -- characteristics the builder and the construction process acquire in these different employment contexts -- we care about. So we say "in-house" or "consultant" in an effort to refer to these characteristics. But the associations are only implied. And they tend to shift out from under us.

Unpacking the associations

The solution here is straightforward: Unpack the associations relevant to in-house and consulting development, describe and name them explicitly, and get the whole discussion on firm ground. There might be other factors to consider, and some might be broken down further, but figure 1 is a good start. The first three concern important kinds of knowledge about the context in which software is to be built and maintained:

• User Intimacy means knowing what kind of users will be working with it.
• Target Awareness means knowing what patterns exist in the processes it will embody.
• Legacy Knowledge means knowing what sort of code base is there to be added on to, or else replaced and migrated from.
• Developers already have, or must somehow obtain, these kinds of knowledge. I'm using the word "target" and the term Target Awareness, instead of the more familiar "business rules" to include educational, scientific, medical, governmental, and other not strictly business FileMaker Pro solutions.

• Development Skills measures how adept the developer is with evolving data modeling and FileMaker Pro coding tools.
• Development Diet means what kind of work the developer spends most of the time doing, whether fixes, tweaks, and add-ons, or else new construction.
• Project Experience is how much the developer has learned about riding herd over the various players needed to design and build good software. Project Experience grows as a factor with project size, clearly -- but remains important even in smaller undertakings. You can always scale more experience down. Inexperience, however, never scales up.