Ok, so I think in a previous post I tolled the virtues of having a VM in my java ee subject to run unix.
I’m falling in love with the increased speed that a virtualised environment provides which I believe is due to more things being kept in memory at a time.
At work today, I used the VMWare virtualisation client to talk to a new virtual machine setup for regression testing and it really makes windows believe that it is talking to a real machine connected to a real monitor. Which helps greatly because QuicktestPro needs a real machine to record errors. To find this option, look in the menu’s of the console for an install windows drivers which will install the necessary components into your virtualised OS.
Anyhow, I found the following page which describes how to setup a virtual windows xp install on the VMWare player. What an excellent way for trialling software and always keeping a fresh install around to compare performance against. I suppose that these steps could be similiarly applied to linux installs too.
VMware Player with your own Windows XP Professional Virtual Machine
Our client, an IT industry group, commissions a system and in the end has no place to put it.
It doesn’t bother me too much. Mistakes happen, people make arrangements that they don’t fully understand then come to realise that those arrangements aren’t suitable. That’s exactly what happened with us.
But then I ask myself…. What is the cost of these mistakes and omissions and more importantly who ends up paying for the system in the end???.
Lets see, we are getting paid a grand total of $0 per hour. But, this project is funded by the state government. The state government is funded by the taxes we pay through our normal jobs.
In fact, I am not working for free, I’m paying them via taxes which are spent on this project. And this project has led me to be dicked around because funnily enough, an IT industry group can’t find a web host. Insert tones of Fred Flinstone grumbling.
The fact that I’ve hit this rock bottom, scraping up excuses and likenesses to Fred Flinstone is not helped by the lack of communication, or the zero take-up of responsibility by the client to chariot the cause and find another solution where there initial one failed.
Alright, so enough of this smellfest, lets put it in perspective.
What could we have done from the start to alleviate the problem?
Set the technology from the get go. No matter how ridiculous sounding, having something instead of nothing leads to an open discussion about reasonable leads and makes the client understand their commitment from the beginning. The solution to all hardware requirements is a chess champion beating mainframe. After that, let the client come back and negotiate with us if they think our selected platform is too expensive.
- Get commitment early on about the platform, similarly as you would have consensus with the client about the intent of the system you are to build. The platform is tied into the end product, and so the features follow on from it. But rather than say, well we need to know the platform and we can’t do X, Y & Z without it, tell the truth. We want this platform and we’ll push and shitfight all the way because X, Y & Z could be done by any talented coder in any language, but we know we can lazily do X, Y & Z with more ease if we strongly push our preferred one. It’s like going for a job. A Java developer won’t necessarily go for ASP.NET if they’ve never programmed in it before. If jobs were scarce and they were cluey, they’d bring themselves up to speed in .NET and have a go at it, but it wouldn’t be without looking at the Java options first.
- We had this opportunity to elect the platform at the beginning and we didn’t go about it the right way. What we ended up doing was taking time to find out each others allegiances and technologies each were comfortable in. More importantly, we thought that we had to work with the clients existing host, and in our eagerness to impress by integrating, wasted time waiting for specs that would never come.
- Initially this point was going to be about picking a platform for your team, sticking with it and forcing your choice on the client, but after writing a few paragraphs justifying that thought, I realise we have a mole in our ranks. Someone who is pushing one particular platform. Maybe a nest of mole’s. The rest of the team don’t hold an allegiance per se, but do hold a resistance to learning new platforms and I fucking hate it. Out of what I thought was fairness, I supported the choice of platform to appeal to everyone’s need of familiarity. But really, as you get more experienced (and I think 3rd year uni students have enough experience), they should be grabbing new platforms like Eve takes apples from a serpent. Yum, yum, stuff the consequences.
If you know your team are going to be shitty if you push the above point, then just pick the consensus platform and push that. Similar to the push a mainframe scenario in point 1, except instead of the client coming back saying its too much, it’ll be the developers crying because those last pieces aren’t fitting together as easily as they thought. At least when the seams start to appear, they will have now learnt a valuable lesson and future projects will benefit because of it.
So in summary, if you don’t want problems with your platform, be rich, obnoxious and proud. Then you’ll just have problems with yourself, not the wider stakeholder community.
Edit: Today there was good news on the hosting front. The client, not our direct liaison, but a member of that organisation all the same took the ball and gave us the commitment in terms of host we needed to start developing.