IT Commandment: Put thy users first, above all else

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. 

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 commandment.  Disclaimer: 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.

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?

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