The same job over and over

For the past 10 years, I had many experiences in the IT field, within different industries (Finance, Telecoms, Retail, Governmental Agency,...). I started describing it all to a friend over a bottle of wine, and came the thought that all the applications were doing was :

1. retrieving data
2. storing data
3. processing data
4. rendering/crashing data

Did it many different ways, following the changes in technologies:  from EJBs entities to Hibernate, from home made Web framework over JSP/ servlet to GWT, or from home made dependency injection framework to Spring, but either it is a retail product, a trade, a Telecoms router configuration or carrots those projects were just data management.

So when most of the jobs require "previous Carrot {replace with your favorite domain} experience", it is basically only vocabulary, speaking the same language, something that can be learned in an intensive week, reading the " Carrot bible".

Working from home and remote locations communication

Usual question comes up in Scrum gatherings or on discussion boards :

How do you do Scrum with an Offshore Team ?

One of the principle of Scrum is normally to have a collocated team. Communication being the main cause of failure of IT projects, off-shoring part of the team is just increasing the chances of failures.

Communication is already difficult when people are located just next desk.
Who never got an E-Mail from a colleague instead of walking over your desk?
And what about working from home ? When the person does not answer instant messaging for half an hour ?
Accepting a working from home situation is acknowledging that the communication within the team is already at risk. Next step could be to simply put the team in remote locations.

But sometimes the decision is not ours, and in that case, the communication should be improved within the constraints. Any means to improve it is welcome.
Phone, webcams, and occasional gatherings (trips) to ensure people trusts each other, and won't hesitate to pick up the phone to call another member if they have a question.

serializable, serialVersionUID and Eclipse

The other day, I saw this in my current project

private static final long serialVersionUID = 1L;

Quick question around, "why are you adding the serial version UID to the class? Are you maintaining it, between different version of the class for clients of the application ? "
Of course not, and I knew the answer : Eclipse throws a warning otherwise, or automatically generates one.
Besides Eclipse configuration, again on an in-house when you exchange the object within the same application (lets say from application server to web server) what is the need of such ID ?

From the Serializable API

 [...]it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization

First, I am wondering how many people having fun with different compiler within the same project.

Then, does it really happen  that you have a different version between let's say a RMI client and the server. Again within the same application I am pretty sure that if you change the server code, you would like the client to have the same version.

And finally, what happen when someone change an attribute of the class ? Well of course the serial version uid is not being changed. ( Similar to hascode/ equals implementations not being updated)

Now let's have fun and check what would happen if I change the class with the same UID, and doing the worst case : deleting a field or renaming one. What happened ? nothing, no InvalidClassException no other exception, the object is just deserialized, with empty fields, since the previous ones have been removed.

Barbie geek !

There is a new Barbie doll that came up couple months ago : the computer engineer ! or should I say the Barbie Geek ?

Well I am not sure about the pink notebook,  the binary screen is  a bit Matrix-like and the T-Shirt quite ugly compared to Roy's fantastic T-Shirt collection. (RTFM Might not be appropriate  though...)

and Barbie's glasses looks like more a librarian than ones Moss have( More on the great show The It Crowd)



Well all  that to say that IT, is definitely an area of men. But apparently, it is not always have been the case.
In the 80's, there was about as many women as men in the IT field - what was 80's IT anyway? perforated cards ?. Some say that it was because computer had keyboard, and therefore linked to the type writing activity - activity linked to the female gender. I believe on the contrary, that it is more a transformation of our society that change a non gender specific activity  to make it a male dominated field :towards the 90',s it then became almost exclusive to men.

In the 80's, PCs became part of the house, and male fascination of the machine combined with gaming experience, led a bunch of boys naturally attracted towards the computer (including myself), wanting to know how that game worked, maybe trying to code their first game. This led them naturally to an IT career, wanting to go on and work on The Machine aka computer.

Then on the computer class, that led of a difference of level : more at ease with the computer through their home hacking, that often discourage their female counterpart. It does not mean that they would be better students, even probably the contrary since they will not empty their cup.

A later obstacle for a girl to pursue an IT career is the image of  the IT student:  a social image of someone sitting in front of a screen 24/7. Not very appealing for a girl, and neither for her parents.

Women apparently have a different view of IT career, wanting to code for a real application like, for example medical research.
In the meanwhile, in other scientific areas, the trend is to tend towards at least an equilibrium, alas not in IT.


Some links:
http://www.womoz.org/blog/?p=13
http://people.mills.edu/spertus/Gender/gender.html
http://www.cs.cmu.edu/afs/cs/project/gendergap/www/papers/IEEE99.html
http://www.cs.cmu.edu/afs/cs/project/gendergap/www/papers/sigcse97/sigcse97.html

Test Driven Reverse Engineering

I stumble upon a piece of code, trying to figure out what the code was doing.
There was some useless comments, and the method I was studying was simply too complex.
To complete the picture, no unit test was available.

So instead of trying to understand the code, probably missing a lot of subtle flows, I created a unit test from scratch. Doing so made me understand the behavior of the particular class.


As in Test Driven Development, you are writing the behavior of the class in the unit test before implementing it.
(Check the very good M. Fowler article)
In my case the code was there, so it was Test Driven Reverse Engineering.
The end result was great :

• I could understand the behavior of the method
• Having a working unit test, I could easily refactor with confidence to make the code understandable.

Code generation and MDA

"Wouldn't it be great if dummy code could be generated ? "

Yes, a great idea that turns out not to be a great one at the end.

I remember the code generation by the Rational Rose IDE. I used it back in early 2000's creating a lot of class, collaboration and sequence UML  diagrams We even made some specific VBA to extrapolate state diagrams, and then generated nice classes, that were basically skeletons. So you have nice diagrams with  the code matching it, and the "Architect" is happy with all this artwork.

Then refactoring came in the picture, the upfront diagrams did not hold very well of course, and at the end those nice diagrams were out of sync with current code, making them quite useless, (but the "Architect" can still show off  his MDA approach of the project to some gullible people).

Another example : generating POJO classes from the database schema/
You can use an hibernate tool to generate, from the database, the associate mapping and the corresponding POJO.
First that remove the ORM from the "hibernate is an ORM persistence framework".
But besides that the very annoying part is that you cannot modify the generated POJOs. Let's say that you want to modify a field, or rename it. Since you would need to modify the create a DLL script, modify the dB, generate the classes, and refresh it in your IDE, more likely you will never evolve to do simple refactoring. You can't do it directly in your IDE. That case goes actually a bit beyond simple code generation and MDA, since it is also about database evolution. Great article and author book about it.

But back to the subject, sometimes the generated classes are missing some behavior that you want to add ( maybe a specific logic for that object - remember that you are still doing OO, or a well defined equals method often missing)... can't do it.

Conclusion:

You must not modify generated code, but you want to since it is part of your compilation / IDE.

So now, why someone would want to generate code?
Because the code is dummy and is redundant with DataBase/UML Schemas/ Existing Code

2 ways I see it :
 - those dummy classes should not exists or should act behind the scene. If the code is generated means there is no logic inside so why even the need of the code ? Use dynamic proxies, dymaic language, anything so that it is not part of your compilation environment / IDE..
 - the code is the design. Diagrams could be used for a sketch but the current design is the code.

Useless Javadoc

Javadoc, similarly to comments , is useless in a in-house project (with no public API), and would show that the class/method is not named properly, or do more stuff that it is supposed to do.
Moreover when it is automatically generated by the IDE ( namely Eclipse),  you might see horrors like that :

     * @param bookId

     * @param bookType

     * @return Book

     * @throws Exception

     */

    public Book geBook(String bookId, Long bookType) throws Exception

Great. Very useful. In that particular case, I'd rather not have any Javadoc since the method is pretty straightforward, and I don't know what kind of exception I would get.
Some argue that Javadoc  could be useful for boundary cases.
" What the method would do if there is no book type with a given type ID ?"
Well return  a typed exception BookTypeNotFoundException and I am sure that you would not need any Javadoc.