I’ve been spending this summer at conferences, giving presentations, meeting customers and the like on a sort of traveling geek safari. My favorite discovery: the software engineer with strong design sensibility is not as rare a creature as first suspected.

It is very rare, the theory goes, to find an animal well-versed in the classic issues of distributed transactional computing and enterprise integration who also has some inkling of (and interest in) humanity. The folks crafting enterprise business logic know how to integrate systems and data, the stereotype declares, but care little about integrating human beings. Server-side engineers who think in terms of data flowing across tiers know a lot about unit tests, but not usability tests; they know a lot about getting data into and out of databases and other EIS’s, but they don’t know much about getting data into and out of people. People work for data in this world.

On the other side of the river are loud and colorful critters who think entirely about users and people, and their stereotype declares that what they do is pretty easy and not all that technical, that they don’t really “get” data-related issues particularly in complex systems, that they refer to tags as a programming language, and they do things that are subjective and creative without being based on actual hard facts. In this world, data should work (but most often doesn’t) for people rather than the other way around.

These stereotypes forbid the two species from mating. Offspring would likely be an abomination of the natural order. And patterns, frameworks, tools, and platforms spend a lot of energy decoupling the two separate domains, so that the two herds may remain fairly separate (at least in theory and in books, though it’s harder to avoid overlap and all the resulting organizational conflict in practice). By the way, I am not at all suggesting that this separation is unnecessary, for I know that it is, even when the rare engineer/designer hybrid is available to the development team.

Ok, there’s also the stereotype that the systems guys are all pale, bald with beards, glasses, and beer bellies (or younger guys who aspire to be bald, bearded, and beer-bellied), and there’s the stereotype that the UI guys all have odd piercings, goatees dyed bright colors, they’re all meeting for an orgy at Burning Man in a couple of weeks, and they all drive Volkswagens. Or something. Tangent.

Anyway, in traveling this summer I have found interesting hybrids between these two beasts. We’ve known for a while that the web has taken some intelligent graphic designers and encouraged them to pick up perl, javascript, server page and xml template technologies, and the like. So some of the people-focused guys have moved a tiny bit into business and systems domains. But like self-taught musicians who play by ear without actually learning theory or musical notation, large gaps can crop up while they’re working (they often get criticized, for example, for building systems that can’t scale beyond the departmental level, or that they know how to build only one app and they build it over and over again with different skins). With a decent framework, these guys do pretty well; a lot of them in the Java world use Struts, but the majority of these guys are probably in the ASP world.

On the other hand, the data-focused guys have shown less interest, my anecdotal perception has been, in moving toward the people-centric domains. With great ferocity they can debate how badly EJB’s suck, and which O/R technology is a silver bullet, but at the same time they don’t even think to question HTML forms and the weaknesses of user endpoints and the absence of a solid enterprise client tier. About this stuff, despite their willingness to debate at nearly every other tier of the enterprise: seldom a peep.

However, I’ve met a few folks this summer who have made either the move from data domains into user domains, or fully from user domains into systems domains. They show terrific and fascinating results in the solutions they build for their customers. Here are a couple of technical observations I picked up from them:

• These systems engineers, who think in terms of data and build with things like messaging, EJB, CORBA, .NET Remoting and the like have a trick: they can think of the user as just another database. Just as database drivers push data into and out of an RDBMS, you need drivers to push data into and out of people. Just as data needs to be normalized to scale and the network traffic needs to be as un-chatty as possible, the drivers to push data into and out of people also need to be aware of relations to user assumptions, preferences and other user-centric information, and need to be as simple and streamlined as possible to avoid hogging mental bandwidth. Linking user endpoints to service endpoints can be viewed as an EAI problem, and user interface is a critical connector from that perspective.

• These guys also understand that alongside domain modeling, object modeling, and deployment modeling, there should be strong user modeling in distributed apps that include human beings among the app’s nodes. When you create use cases or user stories, you will drill down into the use cases and flesh them out with object design – but where do you drill down into the actors in those use cases and flesh out the users? Do you leave it up to product managers and never take a look at it? Getting involved will help define your user drivers, your front-end service endpoints, the objects and services which interact directly with the databases that happen to be implemented as human beings with DNA instead of runtimes with bytecode. Product managers won't think of this stuff, it takes an engineer.

There’s more I intend to share along those lines, but for now my point is just this: There are systems engineers out there, hard core Java dudes, who do care about getting their precious data that last mile into human beings, who are working to add usability testing into their development methodologies, who are not looking down their noses at UI as just creative process and who are looking at it as a fact-based and patterns-governed set of concerns on par with other service concerns in other tiers.

The engineer/designer wildebeest may be a fairly solitary animal, but this summer suggests that it may shortly leave the endangered list. It is still rare, and those of us building products certainly cannot count on its widespread existence. Yet while uncommon, it is an engaging and heroic animal. End user customers would be fortunate if it manages to multiply.