Perils of contracting

I've been working as a freelance contractor doing J2EE work for the past 5 years. I'm not going to get into the whole discussion about pros and cons of contracting versus fulltime employment as that's been done and I probably have nothing to add.

The start of the Java One conference does make me reminisce of the good ole times of working fulltime. My last fulltime engagement was at a large company that treated us very good. We were given the luxury of attending a conference each year as well as freedom to research new technologies in order to keep abreast of interesting developments within our field.

Taking a week off to attend a conference is a hard argument to win when you're a contractor. It's not just the cost that you have to stomach yourself. It's a double edged sword as you need to account for the lost income for that week. Provided you can convince yourself that the conference is worthwhile financially, we contractors are usually working towards unreasonable schedules which make taking a week off a hard thing to do. If it's a longer term contract, vacation is typically available but then do you really want to take your week of vacation to spend at a conference?

Anyways, it is something that I miss.

Contracts. Ahh yes, contracts. My contract for the job I'm at currently is about to expire this week. The "friend of a friend" who got me this job has been nice enough to be charging me a commission on my rate for the past year. Well now he's offered to even more friendly by allowing me the option to buy out of our arrangement by paying him a lump sum of our current commission for the next 5 mths. By doing so, whatever contract I can negotiate this week will be directly with the employer and I will not be paying any 'fee' to our friend anymore.

Sounds enticing somewhat. If I remain employed here for a long time it can be very beneficial for me. However the amount of the lump sum, means I won't see any benefit until next year. What if I'm laid off this year? What if the project finishes and I'm not assigned to a new one? What if I can't stand it anymore and decide to leave? My greedy conscience tells me to buy out and hope for a raise which will shorten the time it takes to see financial gain. My common sense tells me that if this offer were that good, I wouldn't have so many doubts. *sigh* I need to make up my mind after lunch.

System design and planning for the future

How many of you have designed systems and explicitly made decisions based on predicted future needs?

Here's a good example. How many projects have you worked on where a Java Application Server was deemed necessary because "we might need to scale up and cluster for performance and robustness"? How many of those projects took on EJB's for the same reasons?

Ok. Now how many of you have actually seen those systems grow to actually utilize those type of decisions?

My point is, I've seen countless projects where expensive appservers (adds up quickly when you get one for dev, uat, prod..and possibly per seat licence for developers...and then there's support) are mandated as necessary for applications that don't really need more than a servlet engine and a database. Or how about in the early days of EJB's, using all those remote references when the application was always hosted on the same machine.

To be honest, the motives for these decisions (and planning) are honourable but in practice...the situations they were made to accomodate for, rarely materialize. I my experience most systems have a lifespan of 5yrs whereafter they are rewritten. Why not accept the fact that the system is most likely to be shelved after 5yrs and there isn't such a great urgency to plan/design the thing as if it were going to run for a lifetime? I can see the counter-argument where people will claim that with greater usage and higher traffic, the system must be able to grow to meet those needs. Well, with the abundance of testing tools and load testers, we should be able to ascertain whether the system we put into production today will handle that heavy load. If we have that knowledge today, why pay up front in design simplicity and server costs to plan for something that is unlikely to occur?

The Java blogsphere is endeared with these lightweight IoC containers such as Spring and Pico. From what I've seen in my brief experimentation, this paradigm of lightweight servers with pluggable services is the future. The large commercial appserver vendors better have something up their sleeve or open their eyes before they get decimated like dinosaurs during the ice age.

Speaking of pluggable, anyone aware of how to plug in a JMS provider to Spring?

Update on the business venture

Well, I visited Toronto Website to read up on the smoking bylaws and to my dismay it seems that my master plan to permit smoking in my establishment may have it's problems.

Apparently one of the stipulations of being a "private club" is that you have to be a non-profit org. Well, I'm stumped as to how we can make the bar a non-profit organization.

Still awaiting a response from lawyers but things are looking bleak on that front.

Also still looking for a location.