IT Commandment: Put thy users first, above all else

IT Commandment: Put thy users first, above all else

Summary: While the concept of IT commandments sounds rigid and inflexible to me, I will admit there are some core truths that should almost never be violated. Fellow ZDNetter Paul Murphy has recently blazed this trail and it's an interesting experiment in seeing what people believe is fundamentallly important in IT if nothing else, and spark useful debates. IT commandments will be part of a ZDNet blog series over the next week or so.

SHARE:
TOPICS: Tech Industry
13

While the concept of IT commandments sounds rigid and inflexible to me, I will admit there are some core truths that should almost never be violated.  Fellow ZDNetter Paul Murphy has recently blazed this trail (here and here) and it's an interesting experiment in seeing what people believe is fundamentally important in IT if nothing else.  And I have no doubt it will spark useful debates. IT commandments will be part of a ZDNet blog series over the next week or so. 

IT Commandments I do think reality checks like this can help refocus IT thinking on the basic principles that matter.  Because in end, the complexity and technical-orientation of IT can make it genuinely hard to see what's really important.

My commandment, "Put thy users first, above all other things", comes from personal experience. I've had a career delivering IT applications large and small, on the Web and behind the firewall.  I've worked on enterprise architectures, architecture strategy, and business strategy for a variety of different projects and organizations, both as an employee and a consultant.  And one core principle stands out large from all of these various experiences.  The inversion of control, from the organization to the individual, is going to become increasingly and fundamentally disruptive to IT shops that don't obey this commandment. And the world of Web 2.0 only further highlights it.  And that is putting the user and their needs, front and center.  That means going out of your way to know what their problems are, engaging them, and being useful and indispensable.  If you focus on that, you can't go wrong.

Now, some of you might consider this obvious advice, but we witness the breakdown of putting the user first all the time.  One of my favorite citations is that the vast majority of defects in software come not from actual bugs, but from failure to engineer the requirements correctly.  In other words, to figure out what the user really needs.  Now, and this is the tricky part, it is often true that the user has no idea what they need, and can't very well ask for it.  It's up to us as IT experts and software developers to be able to help them figure it out.

Now, there are a couple of root causes for failing to put the user first. One is that software projects tend work in a linear start-to-finish fashion, and it takes major effort to alter this, no matter how spiral, iterative, or agile you think you are.  Why? Because reworking architecture, designs, and code is one of the least enjoyable aspects of software development, particularly if you're throwing away things you've lovingly created in the process. We instinctively dislike and avoid it and it's a bigger problem than we admit.

Example: I once knew of a programmer on an agile project that said they thought they could deliver software much cheaper and faster if they didn't use agile methods, which are often cited as the best process today for building good software.  Counter-intuitively however, the programmer was undoubtedly right.  Agile methods require developing functionality in constant feedback loops that have the customer altering the product requirements rapidly via feedback as they attempt to use it to solve their problems.  Along the way a lot of assumptions are corrected and the real requirements are discovered. But this means considerable rework and refactoring along the way. But the software ends up doing the right things for the user in the end.

The fact is, we innately dislike revisiting and resolving the same problems over and over again, even if that's what we're supposed to do.  And this is why the waterfall effect is still so predominant in our industry.  But it doesn't put the user first and breaks the commandmentDisclaimer: Agile is probably less expensive overall since you throw away less and you don't end up with expensive feature sets that are never or rarely used.

The other root cause is that technology is too often the focus of the IT shop.  Not the lines of business.  Not the needs of end-users.  IT naturally tends to becomes self-serving and self-perpetuating, often the classic walled bureaucracy whose only need is to grow the budget.  And while it's not to say there aren't absolutely terrific IT shops out there (we all know there are), the bell curve tells us that most of them have such a backlog of overdue and unfinished projects that the user community can't even ask it to solve any more problems.  Nor can most people in an IT department articulate the major business problems facing their customers that year.

One of my other favorite stories is by Jason Bell, who left the IT business to run a non-IT business using his own technology skills and found to his amazement that he had abandoned his technology view almost immediately.  Once he was trying to solve real problems for his business, he found he just didn't use the terms SOA, SOAP, J2EE, and his customers didn't ask for them.  This is a key lesson that too many of us in IT take too long to discover; that IT is a means to an end, as enjoyable as the underlying technology is to us. 

Now, don't get me wrong, I do think our industry's fascination with technology is a tremendous enabler and isn't a bad thing at all.  This deep knowledge of the ins and outs of our toolkits allows us to know what's possible; how problems can be solved using emerging new techniques, products, and processes.  It's then that we can try to apply these to solve the problems with our customers.  But we end up stuck in the technologies and far too many of our solutions end up in search of a real problem to solve.  Nicholas Carr, the literate curmudgeon of the Web 2.0 world, brilliantly described this recently as The "Neat!" epidemic.  And an epidemic it is.

IT Commandment: Put they users first, before all other things 

Now, what does all this have to do with Enterprise Web 2.0?  Well, it's specifically this.  As the latest cover of Newsweek says, the coming generation of Web technologies is putting the "We" back in Web.  The power of network effects, mass connectivity, pervasive social software, and user generated content is changing the game.  For one thing, users can help themselves to data and software they need at will. And online software is getting so good, they will do it.  Users can increasingly just route around unresponsive IT.

And so if you're not going to put them first, they will provide for themselves.  A quick search for the right online application and bang, they plug themselves, and the value they create, into someone else's IT system.  Not that you were even harnessing much of what they generated, right?  This inversion of control, from the organization to the individual, is going to become increasingly and fundamentally disruptive to IT shops that don't obey this commandment.

Really, this is just the tip of the iceberg on this subject.  What else is causing IT to lose sight of this commandment?


Our IT Commandments:
  1. Thou shalt not outsource mission critical functions
  2. Thou shalt not pretend
  3. Thou shalt honor and empower thy (Unix) sysadmins
  4. Thou shalt leave the ideology to someone else
  5. Thou shalt not condemn departments doing their own IT
  6. Thou shalt put thy users first, above all else
  7. Thou shalt give something back to the community
  8. Thou shalt not use nonsecure protocols on thy network
  9. Thou shalt free thy content
  10. Thou shalt not ignore security risks when choosing platforms
  11. Thou shalt not fear change
  12. Thou shalt document all thy works
  13. Thou shalt loosely couple

Topic: Tech Industry

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

13 comments
Log in or register to join the discussion
  • Good discussion.

    The only piece I didn't see was consideration of user requirements vs IT requirements. "Security" has been the excuse to prevent users from doing what they believe the job requires.

    Start with the question: Should a user be permitted to install an applications which he, in his professional opinion, believes will increase his effectiveness?

    The correct answer is: "... permitted"?
    Perhaps "encouraged" has a better if still insufficient connotation.

    A service component of an organization has as its first goal facilitating the work of the rest of the organization. Technical issues should be resolved promptly and agreeably.

    Hmmm. Now I see why you left out this aspect of your point.
    Anton Philidor
  • Missing the forest, seeing the trees

    The first 80% or so of this article was spot-on. Then Mr. Hinchcliffe decided to attempt a Gladwell-esque gear shift into claiming that "Web 2.0" is the answer to the problem. Mr. Hinchcliffe has the beginning of the idea, but still fails to see the real problem. People who think that "new technologies" (and sorry to dissappoint you, but the only thing "new" about "Web 2.0" is doing these things over HTTP, everything else in it has been around for 20+ years) are the "solution" are techno-bigots.

    Yes, IT needs to pay attention to the users.

    [b]But not in the way Mr. Hinchcliffe describes.[/b]

    IT needs to stop focusing on the how and start looking at the why.

    I wrote a long blog post about this recently (http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1983228&id=2926438). I suggest you take a look at it and see what I'm talking about.

    Agile programming and all of that is just fine, but you are still focusing on feature sets and not concept. If you pay attention to "why does the user need this, what are their goals", things like "what technology do we need" and "what features are required" fall into place quite easily.

    Web 2.0 is NOT the answer. Users don't need to do "mashups". In fact, "users" don't know how to do "mashups". AJAX is more difficult than traditional Web programming by an exponential factor. Web programming is more difficult than GUI desktop programming by an exponential factor. GUI programming is more difficult than basic CLI interface programming by an exponential factor. Compare the code size (and final compiled size!) of a standard C or Perl (or whatever) "Hello World" program if you think I am wrong. Look at the frameworks needed to make Web or AJAX development "easy". I brushed off an old Perl shopping cart I wrote in 2001 recently. In 1609 lines of code, I accomplished what would take a PHP, ASP, or JSP program a few thousand lines of code. And that included writing a lightweight flatfile database system (including caching of results), a Boolean search system, a templating system, and an engine to run modules. Don't tell me that adding another 50,000 lines of code to make this AJAX'ed is better.

    Web 2.0 isn't about putting users first. It's still about putting developers first. It's about writing a system that is completely inflexible, being dependent upon someone else to generate new features, and more and more and more of the same old same old. Sorry, the last thing I want is to base my business on someone else's constantly changing (but never changing to meet my needs, it seems) Web-based API which they can turn around and force me to pay for (or pay more for) whenever they feel like. I don't call that a step forward, I call it a step backwards. I would rather use well documented closed source code from Microsoft than a pseudo-open source like you find in "mashups" and other "Web 2.0" nonsense.

    J.Ja
    Justin James
    • Part of the reason I posted...

      ... was the implicit assumption that a dissatisfied user is going to leap onto the internet, find the right software, etc. for his purposes, program, and do his work on his own private system.

      Leaving aside all the other impossibilities in that scenario, what would be the response of IT staff to sending data, etc. online without consulting them?

      I don't think they'd be apologetic and abashed. Though they should be.
      Anton Philidor
  • Right commandment, not so sure about the religion

    What's now called "agile programming" used to be called customer prototyping and perfectly illustrates both that IT should put the customer first and that IT seldom does.

    As a consultant I have used Unify's Vision/Accell product several times now to develop the entire customer application in the guise of helping them figure what it's supposed to do -and then simply put that into production on "loaner" hear while the in-house IT picked a technology and redeveloped to their own standards - which never included vision/accel and never improved on the prototype. Indeed one, I believe, is still in production use.

    So I agree with 90% or so of this blog, but the rest of it, well, as Anton points out, all of this has nothing to do with "Web 2.0" - something I believe exists only in a PowerPoint implementation.
    murph_z
  • Baby killer

    "[R]eworking...is one of the least enjoyable aspects of software development, particularly if you're throwing away things you've lovingly created in the process."

    In the screenwriting world, the process is referred to as "killing your babies." To be a successful screenwriter, you have to understand that it does not matter if a line or a scene is the best thing you've ever written. If it doesn't work in this particular screenplay, you have to cut it.
    TimC_z
    • That's hardly a screenwriting invention [nt]

      .
      Omch'Ar
  • There's no such thing as Web 2.0 [nt]

    .
    Omch'Ar
  • I Mostly Agree

    From a purely theoretical standpoint, the post is correct. In the real world, most projects start off with the users not knowing what they want, and certainly not being able to describe it. Yes, part of programming is to coax the information out of the users responsible for communicating the requirements. But in most real-world situations, a programmer almost always ends up taking the lead in determining what goes into an application because few people on the team wants to get "nailed down" by describing the feature requirements, just in case they got it wrong. An awful lot of people out there don't seem to understand their own jobs, and don't want to be exposed.

    So then, it's easier for these types of users to download software (or to use it on-line) because if it's wrong, that user can always blame the vendor to his/her boss. On the other hand, if that user had taken an active role in designing the software with a programmer, that user is partially responsible for the final product when there are issues later on. As a result, most projects don't move forward once you begin to ask the user to describe how a particular model works. The programmer ends up getting behind waiting for feedback, and finally implements something that follows the programmer's understanding of the situation based on his/her research, and not necessarily the actual business model. I've found that the success of any programmer in an industry mostly depends on how well that programmer knows the industry from experience, and rarely on user feedback. That is, unless you get lucky and manage to find one of the few true experts in a field, which does happen occasionally.
    coffeenite
  • You got to talk, talk, talk

    Web 2.0 gets you nowhere, given the problem as it is set out. If users don't know how to describe what they're doing to the IT analyst, and have no idea how they'd rather be working if they had new software to change their paradigm, how are they going to come up with useful solutions on their own? The author is right, in so far as they can mash up a new, irrelevant procedure without resorting to the IT department. They don't need IT; they can screw it up on their own.

    Most workers in the bureaucracy don't know why they do what they do; they only know they've got this job, and the dozen other people they have contact with, and procedures manuals, and the computer screens they interact with, are the things that tell them about their job. Most don't worry about what their company or what their division is supposed to be doing; that's mission, not job. That's out of their pay grade, that will start arguments that just get them in trouble. That's why, half the time, when you ask people how a software innovation could help them do their jobs better, you get crap instead of guidance.

    The agile programming idea is expensive and tedious, and it has the flaw that it potentially has no end. You go out to write programs for your user, but you soon discover that the user is programming [u]you[/u]. However, it has the merit of being the only method with a chance of producing worthwhile products.

    The central solution, and underlying problem, is that the programmer has to be smarter than the user about understanding the user's job. Users can't get the separation from their jobs to gain perspective on what they do, or know how their work fits into their corner of the corporate mission, nor can they think about systems things (like security or reliability.) Half the time even their boss doesn't know half of what they really do. So, the programmer has to circle in on it, asking questions up and down the chain of command, being non-intimidating and seeming interested, so he can win the trust and willing disclosure of information about the organization and the jobs people are actually doing. Then the programmer must have a brilliant idea, and disclose it to the interested parties with enough salesmanship to make it palatable, and then take the feedback to make it a more relevant idea, and sell it again (and sell it to his own boss, too.)

    Programmers bright, aware, and sociable enough to carry all this off are hard to find, though. Darned rare, even. So, what's a good system for getting good results working with mediocrities? Huh. That's a really tough one.
    DelbertPGH
  • Agree

    While I'm not sure about all of the details, I am sure that putting the customer first should be the primary goal of any business, including IT.

    Anybody who ignores their customers does so with great risk, as the customer is the primary source of income - and the customer can always find somebody else.
    CobraA1
  • Put Thy Users First

    If only Microsoft would have used a few of their billions for this in the beginning, they may not have been so detested.
    Dumber_z
  • RE: The IT Commandments: Put thy users first, above all other things

    <a href="http://www.screensavermaker.biz">screensaver maker</a> is the fastest and most powerful tool which lets you make your own screen saver or slide show presentations in minutes.
    2312
  • RE: The IT Commandments: Put thy users first, above all other things

    <a href= "http://www.evdekorasyon.biz/" title="ev dekorasyonu, mobilya dekorasyonu, mutfak dekorasyon, fiyatlar?, " target="_blank">ev dekorasyon</a> <a href= "http://www.filmizlesene.org/" title="film izle, film izlesene,online film,full film " target="_blank">film izle</a>
    delta0x