I stumbled across this post in the DCS Software Engineering forum (yes, it actually works sometimes!)
We're looking to start implementing but have run in to a problem. We are using a package (JBossRules) that has some VERY nice stuff for Eclipse, to the point where development time will be adversely affected if were to not use it.The problem is that the eclipse plugin requires Eclipse 3.2. At present only 3.1 is installed on the student systems.
Now, I'm not claiming that 100% of every project I run is 100% flawless. But in this one post, I immediately spotted three mistakes on behalf of the project manager.
Mistake #1: Fanboyism.
This project clearly involves Java (perhaps that should be Mistake #1?). Java aside, the project manager ahs obviously decided to depend his entire project upon various other Java nasties out there (such as JBoss, Enterprise Java Beans, Struts, etc etc). Fanboyism is a sure-fire way to end up with an Enterprise project (i.e., way larger than it ever needed to be, an over-engineered architecture, and completely and utterly unmaintainble). I've seen it all too many times.
Mistake #2: Failing to work within existing constraints
I'm sure that before deciding his project depended on 'JBossRules', this manager must have known that the student machines have only Eclipse 3.1 installed. This leads us nicely into mistake #3.
Mistake #3: Depending on TSG.
Anybody who's had anything to do with Bob's Technical Services Group knows how unreliable this group is. So unreliable in fact, that the word 'service' doesn't belong in their name. Our beloved manager not only decided to depend on TSG installing a particular package into the student image, they decided to let them know at the latest possible moment (when implementation was supposed to begin).