m christensen wrote:
What you are doing is needs analysis and by definition requires 'help'
or input from others. This is not doing YOUR work for you.
On the other hand needs analysis is much more complex than just asking
users what they want.
Most of the time they simply don't know.
Sometimes, and much lest often than some arrogant developers think, they
are wrong about what they really need.
Sometimes you need to stir the pot some to get people thinking.
Sometimes need to show them potential options to get them thinking.
Definitely true. Developers often fall into the false dichotomy of
assuming that software design means implementing either a user/marketing
wishlist or a lonergeek's personal idea of what's best. The former
almost never works and the latter works well in some very limited
domains but poorly everywhere else.
Proper needs analysis requires:
-- Identifying the users ("customers").
-- *Understanding* the *tasks* the users need to accomplish, and
understanding them first in task-oriented terms ("business processes")
rather than implementation-oriented terms. Otherwise you wind up with
"XY problems" where what's really needed is a way to accomplish task X,
but the developer/users/both prematurely decide that the way to do it is
with tool/implementation Y, and the focus shifts away from the actual tasks.
-- Learning how the users currently accomplish their tasks.
-- Learning in what ways the users' currently method of accomplishing
their tasks fails to meet their needs. This is more than just asking
for wishlists. It requires working with the users, who may not be able
to immediately articulate their needs. One of the most important
aspects of this phase is recognizing what *doesn't* need to be changed.
It is also an almost certainty that simply trying to automate an
existing manual process will be unproductive and merely increase complexity.
Note that all this does require some "social skills" such as listening
and perspective taking, which puts off some geeks. But it does *not*
require a bubbly, glib, extroverted personality, and the assumption that
it does is really just an excuse for not doing the work. It's really
just a matter of disciplining one's mind, comparable to disciplining
oneself to finish designing an interface before diving into the
implementation. The lack of such discipline leads to interfaces that
are organized around the implementation rather than vice-versa.
In Mr. Newby's case, the first step really should be to see what's
currently being done with GUIs for SQLite; what's out there, and how do
they differ? Some of the acrimony in this thread came about because he
skipped that step. Then the next step should be asking who's using what
tools, what tasks do they use them for, why did they choose them, what
do they do well, what do they do poorly, etc.
