Wednesday, August 11, 2010

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".


    Tuesday, June 15, 2010

    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.

    Thursday, April 8, 2010

    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.

    Monday, March 22, 2010

    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


    Wednesday, March 17, 2010

    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.

    Tuesday, March 16, 2010

    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.

    Tuesday, March 2, 2010

    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.

    Thursday, February 25, 2010

    It's possible to change it ... Code ownership

    Another day, another story...
    I stumble upon one piece of code, that caused an NPE.
    It could have obviously been avoided doing a small refactoring so that any client of the code, no matter what, would not get an NPE. Doing so would have meant to delete one method, and possibly break the compilation of any client calling that code, but instead of a runtime NPE a compilation error is way better.

    So I asked around, why it was not refactored :
    "You can change it, but it will be your responsibility if it make fails other projects"

    Nice.
    If you are not too scared of being held responsible of another project delay, this would stay in the same state, and the NPE was normally fixed so why bother ?
    Or you can do it like in cowboy style ( also known as Rambo style) doing all the work by yourself.

    Both cases are not ideal, and the cause was :
    • there were no true Continuous Integration and appropriate testing strategy. As a consequence every one fear the change.
    • There is a sense of code ownership or I would even say worst : a disownership of the code :" It's not my code"
    Because the next step of the Strong Code Ownership  , is the No OwnerShip at all.

    The only way to go is obviously the Collective Code Ownership. Doing Pair Programming helps to get that sense, and Code Review, is another way if Pair Programming is not possible.

    And then the "Knowledge Transfer" when someone leave the team becomes obsolete and useless.

    Knowledge Transfer word is a Team Smell to see that they are not working in an "Agile"  way.

    Wednesday, February 24, 2010

    Semantics of Collections

    What is up with the java.util.List?
    I see it so frequently used, and most of the times to return collection of elements that are not ordered.

    The true semantic of the List is  an ordered Collection
    Most of the case the API returns unordered elements that are not duplicated. It is then the true semantic of a  java.util.Set.


    If the API returns an unordered, collection of possibly duplicated elements, then the returned type should be a Bag (or Multiset from Google Collections) , and the semantic would be correct.

    At least, in doubt I'd rather get a java.util.Collection than the wrong returned type.

    Monday, February 22, 2010

    Relection equals Matcher - Easy Mock made even easier

    Easymock is great tool to produce mock object and do true unit testing verifying the expected behavior of your class.

    One issue faced times to times is  while verifying the behavior it uses equals to verify objects passed as arguments are same.

    It should work great in most of the cases, but living in the real world most of the times equals is not defined.
    Of course you should define a true equals function, but sometimes you can't even do it, since you might not be able to modify the parameter.
    Arguably you want to test the behavior of your class, no modifying the argument itself.

    So here is a simple Matcher using Apache commons EqualsBuilder:
    public  class ReflectionEqualsMatcher<t> implements IArgumentMatcher
    {
        private T expected;

        public ReflectionEqualsMatcher(T expected)
        {
            this.expected = expected;
        }

        public static <S> S eqReflect(S toCompare)
        {
            EasyMock.reportMatcher(new ReflectionEqualsMatcher<S>(toCompare));
            return toCompare;
        }


        public boolean matches(Object o)
        {
            return EqualsBuilder.reflectionEquals(expected, o);
        }

        public void appendTo(StringBuffer buffer) {
            buffer.append("eqReflect(");
            buffer.append(expected.toString());
            buffer.append(")");

        }

    Friday, February 19, 2010

    Deprecated is bad in application code

    Deprecated should be forbidden and never be used when coding an application.
    The sole purpose of the Deprecated tag  ON AN API is

    • It is insecure, buggy, or highly inefficient
    • It is going away in a future release
    • It encourages bad coding practices
    ( from Java's  Deprecation definition)

    When developing in-house software, when you have no outside client of your code it does not make sense at all.
    Most of the time it is used when the developer is afraid to delete or modified the class/ method and therefore add a deprecated annotation instead of  refactoring.


    It should be part of the code smells indicators along with commented code.

    Monday, February 15, 2010

    The multiplication of TODOs

    Times to times, you must have seen in the existing code something like that

    // TODO Auto-generated method stub
    return null;

    Great. Without knowing, you might call a method that is not implemented, and get a wonderful NPE.

    I also like the

    //TODO to fix later

    Yeah right, it will be fixed.
    Now the funny part. Let's go to the TODO tab in your IDE, and count the number of TODOs in that existing project: 890 for 320 files. An average of 3 TODOs per file. Wouhou !

    Enough of ranting.

    To avoid that, change your default file template, to instead of adding a TODO and return a null, throw a runtime Exception like:

    throw new UnsupportedOperationException("This method is not implemented");

    or even better use an explicit NotImplementedException:
    throw new org.apache.commons.lang.NotImplementedException("TODO");
    That is first step. Now the only way to enforce that the TO DO will BE DONE, is to create the / modify the test calling that piece of code. It will fail and force you to act.

    Concerning the Fix Later example, I would recommand the use of a TODO to issue tracker converter, so that item would be part of the backlog, prioritized, and eventually done in some future iterations.

    Friday, February 12, 2010

    Commenting old code is useless

    Why do people comment out old code ?

    There is your favorite SCM for tracking the changes that happened in the particular piece of code.
    So why ?
    Because people are afraid of the change, afraid of breaking something.
    They comment out the old code, so that if something happened during the Big Testing Phase, they could revert.

    Commented code means no code coverage, i.e. no unit test.
    Bad.
    Commented code should be added as one of the code quality indicator (or technical debt management) like Sonar, because it smells like something not right is going on.

    Thursday, February 11, 2010

    Some quotes on Unit Testing

    From an old article of Heinz Kabutz

    JSC: What are some of the big mistakes that even experienced Java developers make?

    Kabutz: Not unit testing. At conferences, I ask, "How many of you have unit tests for your code?" Almost no one raises their hands -- and these are experienced professionals. While programmers start projects believing they should have unit tests, they often don't take the time to write them up front, and they end up spending time fixing bugs. We should always perform unit tests.

    A good unit test will not only flush out problems before you get close to production, but it will help regression test your system as well. I see it over and over -- very few companies have the discipline to enforce the use of unit tests.

    And a following interview of Joshua Bloch

    JSC: Java Champion Dr. Heinz Kabutz finds that failure to unit test is a big problem among Java developers. He reports, "At conferences, I ask, 'How many of you have unit tests for your code?' Almost no one raises their hands -- and these are experienced professionals." Your reaction?

    Bloch: I'm really sorry to hear it. Unit tests are essential! If you don't have them, you don't know whether your code works. Having a good set of unit tests gives you much more confidence that your code works in the first place and that you don't introduce bugs as you maintain it. Inevitably, you will introduce bugs, but your unit tests will often let you find the bugs as soon as you introduce them, so you can fix them before they cause any damage.

    Arggh, this was 2007.

    3 years later I still see project /organization that does not believe in unit tests, and where I hear " We don't have the bandwidth to do unit test".

    Prehistoric software development. Upfront tests, TDD, anyone ?

    Wednesday, February 10, 2010

    Sans maîtrise, la puissance n'est rien

    Pardon my French : "Power is nothing without control" was a famous commercial catch phrase from a tire company.

    It made me think of a project and agility methodologies.
    How is that one translated in the IT world :
    "Latest technologies is nothing without control of the technical debt."
    Not very catchy but so true.

    One example:
    On this new project, designed to replace legacy systems, you take the latest technology stack, add some very knowledgeable developers.
    But without using any XP principle or any dogmatic approach: no true unit tests, no true continuous integration , no knowledge sharing but in big lengthy meetings ( of course no pair programming or code review , uh what is that?).

    Shake it and let it marinated for 2 years. Open it and you'll smell a very strong technical debt.

    Nothing can be changed, because of the fear of breaking something .
    Not mentioning the lost knowledge of why it was designed like that.

    Forecast result : the developers play the job security becoming all Bob the developer's types, and your new top notch application is now really a mammoth application.

    Back to Square one. Same player play again.

    Thursday, January 28, 2010

    Unit Tests vs Integration Tests

    Let's make it quick and clear :

    If a test is not executed on a regular basis, through the build process or continuous integration it is therefore not maintained and becomes a useless test. Maven users would recognize the over-used -DskipTests=true. You can delete it right away, because chances are that within no time it will fail.

    Why would you not want to execute the test all the time ? Simply because what was thought to be a unit test is clearly not.

    Then how to determine if a test is a Unit Test or an Integration Test ?

    • If a test needs data in the Database , it is an integration test
    • If a test needs a Spring configuration, it is an integration test
    • If a test needs a server to be up (Jetty or application server) it is an integration test
    • If a test is slow it is probably not a unit test.
    • ...
    well you get the idea.

    A unit test is testing one and only one class.

    It does not mean integration test are bad, but they need to be executed in a different cycle from unit test: for example once the build is deployed on a server, etc...