Eidos in Montreal

Eidos officially announced they will need 350 people in Montreal by 2009. This is while their competitor, Ubisoft, mass hired a lot of people in its Montreal office which at the end resulted in a sharp salary increase for most developers. The same thing is going to happen when Eidos starts sending recruiters around. I have been studying Montreal job market for a while and apparently Montreal is running out of tech work force. Hiring a developer is going to be simply impossible. Montreal has so much opportunities now that even after Motorola's close down nobody heard of excess of work force. I have seen companies putting an ad for more than 3 weeks.

Another side of the story is that this is happening while lots of software houses are running on a low and tight budget. Guess what? Most of these companies will not be able to keep their developers by next year and they will have to close down or find other sources of financing.

Less code or what?

My philosophy of coding is less code is always better*. That is, less code needs less effort to maintain and in case of bugs you need to examine less code to spot where a bug lives. This is important when a legacy code is being maintained. It is usually acceptable to disable a legacy code to implement a new feature or fix an existing bug. During this process, some code usually becomes redundant and it should be thrown away. However, this is scary. I haven't seen a lot of developers that feel comfortable by deleting other people's code. I understand this to some extent. On the other hand, leaving a redundant code in place is scary too. Redundant codes confuse developers. Experienced developers usually come to this question of why the hell this code is there and they usually spend days to find out well sloth is a real sin. This is when people should throw code away. Throw your redundant code away, and by code I mean any form of code, either Java code or SQL statement.

 

 

 

 

* This excludes crazy untraceable codes that break code usage searches and, therefore, prevent refactoring tools from functioning. One example is Java Reflection API which may save few (hundred) lines of code but it lets your code live as shadows.

Free IntelliJ IDEA upgrade

Today I got my free IntelliJ IDEA license upgrade. Yet another reason to love IntelliJ IDEA.

IntelliJ IDEA 7 - method does not exist and more

For a while I was getting annoying errors in IDEA early release distributions thorough their EAP, and this was becoming an issue as the errors were disabling basic functions like code highlight. I was quite concerned that IntelliJ quality is going down but at the same time I didn't think I was right to say it because those distributions are not really meant to be stable. However, after a few tinkering here and there I realized I was getting those error because I was extracting new releases on previous releases and apparently it was not the best thing to do. One still may keep the bin directory but it is not too bad of an idea to do a clean install each time.

In any events, IDEA 7 has a nice Spring and Hibernate support. I have been enjoying code completion for HQL queries and Spring beans. Every now and often I can see a minor false-positive error detected in my HQLs but I have a feelings these things will go away in the main release of version 7. No matter what, I still prefer to stay a customer. I can't find my way in Eclipse. Therefore, that's not really an option for me.

Code Quality

Seriously, you need to think twice if your class has 2800 lines of code! And please don't comment your code with obvious sentences. Having no comment is a lot better than having a stupid comment.

 

Stupid comment example 1:

// Checks if total is greater than limit.
if (total > limit) {
 doScrewThePerson();
}

Stupid comment example 2:

/**
* returns the favourite person
*/
public Person getFavouritePerson() {
    return this.favouritePerson;
}

Business Value

Few months ago I started working on a software that is in production now for I don't know how many years. My assignments primarily were supposed to be maintenance sort of tasks, but I somehow ran into this situation in which I didn't believe patching the code to add new features was a good idea. I skip my justification at the moment for it is not the main idea of this entry.

In any events, I started evaluating the existing code and no matter how I looked at the code, I didn't find a straight way to keep the existing code. My assessment was the back-end layer should be completely replaced, the front end should be modified to adhere to technology standards, build files should be revised throughout the system, and packaging needed a serious attention. My rough estimation of how much time I needed to do this was something around a year. This may sound stupid since no one is going to wait for me for a year to have a new system that does (I am crossing my fingers) exactly the same thing as  before plus a minor new feature! On the other hand, this is not totally stupid because after the changes are done the system is better maintainable and new features will roll in as they are needed.

Having considered the above criteria, I started to think what parameters help one think his/her way out of these situations. I mean one needs to plan what to do first, and he/she should find a way to keep everyone happy. After all, technical managers don't like setbacks and delays and product managers want to be able to make promises to customers (and possibly meet those promises). One possible guide to find what to tackle first is to determine business value of each change. Most likely many changes do not have an immediate business value; therefore, they should be given a lower priority. Changes that possibly take a long time should be broken into smaller parts that can be finished in a shorter time, even if this will make the whole thing take longer. My point here is that business people do NOT care how perfect a code is, but they seriously appreciate seeing something that works but is a little slow or doesn't have A or B. This is something that developers don't usually understand.

I will try to give an example of how I think things should be in another entry.

+1 for Java Closures

After all these years of being a successful nerd I feel like I have been the wrong kind of nerd. Read this.