Creating a multi-tier client/server application

[Bruno Desthuilliers]

Jeff a écrit :
> 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,

You could explore something like a custom-made GUI client app 
communicating thru the http protocol with a web-server app. http is just 
a protocol, and it doesn't necessarily imply using html and a browser... 
IIRC, some GUI toolkits uses XML description files for the UI.

(snip)

> 3) Easier to "lock down" who's using the program by only
> installing it on certain machines.

Not a very reliable security scheme IMHO !-)

(snip)

> Which leads me to the discussion of planning:  
(snip)

> 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.

Extreme Programming doesn't mean "no preparation", and makes heavy use 
of use cases. Of course you need to have some - hopefully accurate - 
functional specs. The point was mostly along the lines of "don't try to 
have full-featured detailed design before you start coding, because 
chances are it will be wrong".

> 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.

Which would be totally non-sensical. I don't believe anyone on earth 
could come up with such a thing - done right - *before* the application 
is written.