location of "Important directories"
This project seems hard to install.
The documentation advises
you to "See Important Directories You Might Need to Know ", but that link is broken ($APPATHS is not defined). It also asks you to look in the help menu, but if you don't have the jars installed, the app wont start and there is no help menu.
Current time expended on this (not completed) project (using pen and paper accounting method) = 3h. :)
Could the doc writer please give a bit more guidance as to what these important dirs are, and where they might be found.
working effectively with programmers requires some skill and sensitivity
1) How do you consider that your relationship with these developers will alter after you have publically expressed your feelings about them in a forum where they are unlikely to feel that they have a comeback. ( What programmer wants to reply to the old comment "anyone but an idiot would .." by sticking up their hand and identifying themselves as that idiot!
2) Programmer- user relationships are shaped over a long period of time. One wonders whether there has been a history of false bugs, programmer bullying, and that you are seeing jadedness on behalf of your programmers.
3) Your comment about "5 years experience with similar applications" flags to me that you may have fallen into the classic hubris that kills many technically skilled people - that great expertise in one area is not instantly transmutable to great expertise in another without effort. Many windows power users actually believe that linux is unfriendly for this reason :)
4) I assume that your programmers are male. I have seen plenty of IT projects fail due to the incapacity of young, skilled, mobile, male programmers to take proper bullying from middle aged management. Sounds a bit like an old bull/young bull issue to me.
5) In general terms, and not related to you in particular, just because a customer/user can define the problem doesn't mean that they can manage or direct the solution. If the spec is "Let there be light" - you would be supprised at how many times some customer will tell you what you need to do. Understanding the problem is not the same as solving it, although it is a necessary first step. This is very irritating to programmers, and other people who have to "do".
6) Not many customers/users are familiar with what I call the "degrees of freedom" problem in programming. That is where extra features requested after the initial spec become progressively harder to add, due to constraints (ie reduction in the degrees of freedom or number of possible options) caused by the programmers solution to the original spec. The classic examples of this are in database programming when some bright spark wants to pull out data which was never entered into the database, but which can be inferred from it with a lot of logic. "But I just want one more field! why has it taken a week?". The programmer has initially taken an approach to solving the problem, and coded in as efficient a way as possible, based on what they think is a complete spec. Of course, most good programmers are partially resistant to this, they get a knack of leaving open as many of their options as possible, and a sense of the kinds of mistakes that customers are likely to make in their initial specification.
Having to throw out a large chunk of work to impliment a tiny feature usually is resisted by most people. Do this to a good programming team more than once or twice, and you may well ruin it. That is, you will lose your capacity to get good work done by that team. This is often a management/specification problem, and particularly manifests itself when there is a committee overseeing the project.
7) Perhaps you are unlucky with these programmers. Perhaps someone in your organisation is more successful in managing them. Maybe you need a middle layer of project management - someone that they and you respect - to manage this.