September 14, 2009, 9:12 AM — For a long time now, I've been one of those power users who are either fun to work with (no need to explain painfully obvious basics to me) or a developer's nightmare (two words: scope creep). Lately, though, I've been dwelling on the other side, actually developing a database project to be used by several dozen of my colleagues.
While I've coded internal tools before, those have typically been along the lines of: "Here's what I came up with. Like it?" This one is an official project, complete with requirements and meetings and, yes, change requests . And there's nothing like living someone else's job for a while to truly understand that a request for just one more "little tweak" doesn't seem so minor to a bleary-eyed coder who's just finished a 4 to 8 a.m. coding session.
If you're nodding your head in agreement here, though, I feel compelled to point out that it may have been quite a while since you were on the other side, the side that most users (including me) usually inhabit: having great need for improved technology to boost efficiency but little ability to make it happen.
That feeling of powerlessness is something I've got to keep in mind now when users come up with some great new feature for my little project. Sharon the editor would be agreeing with an idea for expanded functionality, and very possibly chiming in with an addition of her own. We users have a lot of work that needs to get done, and the ability to perform tasks in an easier, more elegant or less taxing manner is extremely appealing. And since we can rarely code systems on our own, we often feel at the mercy of outside forces when we're told, "No, you can't have that."
Sharon the developer still says "Sure, no problem" to some ideas. But other times, after realizing the amount of work involved, it's tough to keep from blurting out, "Are you kidding? No!" What Sharon the coder needs to remember is that Sharon the user's requests aren't aimed at generating yet more hours of work for the development team. Often, I come up with new ideas for project features because I've bought into the usefulness of the original idea. And usually I have no way of knowing whether a suggestion represents a relatively easy add-on or a nightmarish week of more work.
From my temporary perch astride two worlds, I've rediscovered the importance of communication . Users making requests often don't differentiate between "This would be nice" and "That would save us hundreds of hours over the course of a year." On the other side, tech teams usually have good reasons for saying yes to some requests and no to others. But if developers only say things like "You should have thought of that earlier" or "We're too busy" -- and if they don't occasionally say yes or offer reasons for saying no -- users will just get frustrated. Users get cranky when we feel we have no control over the outcome.
Developers do too, of course, which is why it's so important not only to communicate in some way, but to make sure messages are understood and not simply received. Some advice that writers learn in journalism class is equally useful for project teams: Show, don't tell. Or as Matt Wait, key developer for the Pulitzer Prize-winning political database Politifact , says: Demos, not memos.
This Journalism 101 idea is something I've needed to relearn during my brief coding stint. Not everyone can grasp the advantage of putting information in a database instead of e-mail or a free-form text document. Actually demonstrating the slicing-and-dicing capabilities of a database can get more people enthusiastic about its potential. And that's a good thing -- even if it means a slew of additional requests for new features.
Sharon Machlis is Computerworld 's online managing editor. You can reach her at smachlis@computerworld.com and follow her on Twitter at sharon000.
