OK, so I haven’t blogged much lately. Now that we’ve got the new mainframe in production maybe I’ll be able to find more time for it.
I’ve been reading a book I got when they closed down the 13th floor library, The Trouble with Computers by Thomas K. Landauer. It looks pretty good, except it was written in the early 1990’s before most people had heard of the web, so I’m not sure what he might say differently if he were writing today. Anyway, I wanted to quote this:
It is not only the initial design of computer software that is thus so often flawed. The way in which software is produced and deployed makes it almost inevitable that it will miss its mark in providing the right functions for its users. After the initial specification of a product, which may involve executives and managers of the people who will use it, some of whom may have done the job at some time in their past, software is usually developed by a group of programmers with no further contact with customers until the system is complete. The programmers add and subtract features and functions reflecting their own fantasies of what the job is like and under the assumption that the users are people just like them, which is never true. Systems are only rarely tried out on users in their environment before they are sold.
I think this is one of the things we’ve been able to do right in the past. *DACCT (the predecessor of *DEFINE) came about when John Wheat went and sat in departmental accountants’ offices and watched what they were doing. Having programmers working in the departments they support helps too. This is not to say we couldn’t do even better in the future.
It does help, although I think as much with the prioritization of IT efforts as with understanding. Having spent the last four years in FIS after all those years with DP/ACS/ITS has given me a different perspective on things.
One of the things you here Paul Graham advice startups is to release _something_ as fast as possible, so that you can get actual feedback from users. Many shops (including the one my wife works in) use an “agile” process to try to do the same thing — make small improvements, release, get feedback and start the cycle anew. It’s really an allied idea (with new packaging).
Glad you might have some time to blog; your perspective is always interesting.
wish we could edit comments… “hear Paul Graham advise”. I am a terrible proofreader, and my fingers seem to type what they hear. 😉
One big impact of web-distribution is that the more savvy software developers can get feedback from their users even when their users never talk to them. For example, which features never get used, or which pages result in a lot of unproductive click-trails (sign of a confusing interface). Also, you can (if savvy and careful enough) get input on a wide swath of users’ habits, not just the most talkative ones.
You can also roll out a feature to a certain subset of your users, and roll it back with relative ease.
None of which would go over well here, I fear, for political and cultural reasons. Perhaps it shouldn’t. But the speed with which web-based software can get user feedback is (literally) orders of magnitude faster than the way we currently do.
Actually, I suspect that well-done A/B testing gives better results, in terms of real behavior, than interviewing users does. We all _think_ we can answer questions about what features would help us the most, but often the real answers are surprising.
Or so I suspect; who knows, maybe A/B testing would prove me wrong. 😉