The Artima Developer Community
Sponsored Link

Weblogs Forum
Geek Wildebeest: The Designer/Developer, No Longer Endangered

3 replies on 1 page. Most recent reply: Feb 28, 2008 12:30 AM by Alexei Kaigorodov

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 3 replies on 1 page
Sean Neville

Posts: 29
Nickname: psneville
Registered: Jun, 2003

Geek Wildebeest: The Designer/Developer, No Longer Endangered (View in Weblogs)
Posted: Jul 18, 2003 8:43 AM
Reply to this message Reply
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.

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.

Chris Hartjes

Posts: 12
Nickname: bloodshot
Registered: May, 2003

Re: Geek Wildebeest: The Designer/Developer, No Longer Endangered Posted: Jul 18, 2003 1:07 PM
Reply to this message Reply
I would like to think that I am becoming a Geek Wildebeest as my career progresses. But the only way you become one is when you start caring about more than just cranking out code.

Mik Lernout

Posts: 10
Nickname: miklernout
Registered: Jan, 2003

Re: Geek Wildebeest: The Designer/Developer, No Longer Endangered Posted: Jul 22, 2003 3:07 AM
Reply to this message Reply
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.

Alexei Kaigorodov

Posts: 3
Nickname: rfq
Registered: Jan, 2008

Re: Geek Wildebeest: The Designer/Developer, No Longer Endangered Posted: Feb 28, 2008 12:30 AM
Reply to this message Reply
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.


Flat View: This topic has 3 replies on 1 page
Topic: Geek Wildebeest: The Designer/Developer, No Longer Endangered Previous Topic   Next Topic Topic: Python 3000 podcast interview with DDJ

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use