Sponsored Link •
Observations on the summertime mating practices of systems engineers, well-versed in moving data into and out of everything non-human, with interface designers, who it turns out are obsessed with more than just collecting new fonts for annoying ad banners.
Ive 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 EISs, but they dont 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 dont 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 doesnt) 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 its 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, theres 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 theres the stereotype that the UI guys all have odd piercings, goatees dyed bright colors, theyre all meeting for an orgy at Burning Man in a couple of weeks, and they all drive Volkswagens. Or something. Tangent.
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 EJBs suck, and which O/R technology is a silver bullet, but at the same time they dont 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, Ive 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:
Theres 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.
|Sean Neville is a software architect at Macromedia where he is focused on creating the Flex platform. His previous projects include the JRun application server and Flash-related products for J2EE and .NET. His experiences include membership in the JCP Executive Committee and numerous JSR expert groups; authoring articles, contributing to books, and speaking on enterprise topics; financial services app consulting; building doomed yet fun web startups; maintaining open source projects; and half-decent fiddling of Irish jigs and reels.|