Creating a multi-tier client/server application

[Jeff]

Thanks for the quick responses.

I was really hoping to avoid an entirely web-based app, for a few
reasons, not the least of which is that I've been working almost
entirely on web apps for the past few years, and I am getting mighty
sick of it.  A lot of that is due to the language (PHP, which I have
since grown to hate) I had to use.  I've worked on a site for my self
in Python (using Pylons, actually--which is excellent) which was
vastly easier and more fun.  But I'd really like to try something
different.

Now, of course, that's not enough reason to force such a thing onto my
clients (when I say clients, I mean the ones that are paying for this,
but they're really within my same department, so they actually have
working technical knowledge.)  Some reasons for them would be (in no
particular order): 1) More responsive and user-friendly interfaces, 2)
Much better ability to sort, export, import, and print data (very
important), 3) Easier to "lock down" who's using the program by only
installing it on certain machines.

Paul, I've read through a bunch your conversation with Chris--for
simple applications, yes, you're right, why not use the browser?  But
for a lot of this I have to agree with him (although I don't
particularly agree with his tone, but that's irrelevant.)  This will
be a complex enough application that certainly simple HTML & CSS won't
be enough, and the thought of the sheer amount of AJAX trickery (yes,
trickery) that I'll need to use just to get it even *close* to the
usability of a desktop app is rather frightening.  I've done plenty of
stuff with AJAX, and it certainly has its purpose, but it gets
incredibly bloated and fragile *very* quickly.

This application will be used by hundred of people (some of them will
be using it more or less constantly) across several departments in a
large university (Rutgers, if you're interested.)  Because of that, it
needs to work, and last for years--with changes over that time, of
course, but no rewrites--a lot of their current systems are FileMaker
Pro databases... all I can say is, "the horror".  They've used some of
these systems for the past *ten* years with their "databases" breaking
several times a *week*.  Now, they want something that *works*.

Which leads me to the discussion of planning:  if this were a basic
application for myself, I'd plan out the basic objects and database
tables I'd need, and how they should interact--maybe to some extent
what the user interface should work/look like.  But I'd certainly be
flexible.  In this situation, however, I have no such luxury.

This system will be used, often, to figure out how much people should
be paid (and then interface directly with the University's payroll
system), and store lovely things like SSNs, and will also have to have
somewhat crazy business logic to track when hourly workers are
eligible for raises, if they took enough training classes, etc.  There
are a lot of people with a stake in this system, and I will need to
work with them very closely on how this should work, and they sure as
hell don't want any surprises.  My manager even wants use cases (if
you've never had to deal with use cases, consider yourself a lucky,
lucky person) which I am going to attempt to argue as that is even
going *too* far.

So, long story short (too late), no Extreme Programming for me.
Hopefully, the amount of planning will be somewhere in between that
and the bureaucratic nightmare of documenting up front what each
module, class and function will do.

Thanks again for your advice--I really appreciate it.