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:
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 apps 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.
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.
I agree with the sad observation of the current status-quo, where the common variant of the engineer-species is not very aware of users and doesn't really care to be. We can only hope that this wilderbeest - mutation will become more and more common place on the plains of Software Development. But aren't XP and agility very much directed to that, to follow the analogy: aren't they like radioactive spiders roaming the fields and forcing genes to evolve?
Related: one of my primary motications for working in development is the ability to sit down with a user/customer, to talk with him and to understand his problems and being able to propose solutions to them that he could have never imagined. For me that is the greatest problem in software development nowadays: instead of talking to the world, we are talking 24/7 to each other... Thank Sean for reminding us again.
Very interesting point, and its a pity theat there are so few replies. Looks like developers and designers are still sitting in their own digs. Being a developer (bald, eye-glassed, and bellied), I was thinking a lot about problems of distributed computing, replications, coherence, pessimistic and opimistic transactions, reconciliation etc. What I found is that common mistake of researchers in that filed is that they think of data as something given and forget their source. And the source is 98% human beings, 1% data sensors and only 1% computers themselves. Thinking of data as a result of computation of human willings can greatly help in constructing scalable, reliable, secure information systems.