Eric Bohlman wrote:
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.
Along those lines....
I do use SQLiteSpy. It is handy for quick high level poking around in
the database.
Honestly my major use is to hand it and SQLite databases off to end-users.
I'm the QA manager on an Oracle Project.
I have test scenarios that hit almost distinct 2,000 columns in a large
automated test scheme.
I use the Issue tracking system 'Trac' which used SQLite as the database.
Most of my test harness is written in Perl, the data is actually pulled
from Oracle into packed records in SQLite and the tests
hammer on them locally. This is about 4 times faster that working in
oracle ;-).
The test results and logs are written into SQLite databases and are then
checked into a Subversion revision control repository.
Trac Tickets are built that point to those database files in the repository.
This gives me a static and self contained snapshot of the data, logs and
test results.
My end-users are analysists and developers.
Our project is a database-centric back-office app and EVERYONE knows and
uses SQL heavily on a
daily basis.
BUT most of them use TOAD as a client and although they type complex SQL
statements in all day long,
they are used to the results coming back in a table format they can
scroll thru and cut-and-paste.
Some of them almost had a stroke when I told them Yes, it's in a
database, but it's not Oracle.
SQLiteSpy gave me the ability to tell them to open the Trac ticket and
double click on the logs and up
they come with a GUI. (No retraining required ;-) )
Marc
