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. -- http://mail.python.org/mailman/listinfo/python-list
