Monday, December 7, 2009

tip of the iceberg - gems of architectural fuckups - java

Basically when you see something in the code you should start thinking about the motivations of the programmer who put that there.
For example when you see a loop with System.out.println(...) in part of the initialization code you can be sure that someone
  1. was checking if all the stuff was initialized
    1. this means that something wasn't initialized
    2. it is not trivial how to do it
    3. people have no guidelines/was not educated about the framework they using
    4. someone who should know about what developers do has no idea
    5. some may found a workaround already and done the initialization in some other way
    6. bonuses will be paid to people who will fix the code when the management understands that it is to be rewritten.
    7. no one was performing code reviews / peer reviews
    8. log4j was not configured/used properly in that project as no one cares about maintenance
  2. the developer has a taste for quick and dirty methods
    1. he was hired so this method of work is accepted/encouraged
    2. he has no support for doing the things in a civilized manner
    3. he was never blamed for doing so and his check in-s are not supervised
    4. most likely more than one developer let it pass as they was no intention/instruction to remove it (it is somebody else's problem)
    5. deadlines are rated more important than quality
    6. the customer has no idea what is going on, just pays a lot of money without having enough control over the project. 
    7. #5 means that the customer has project managers hired for the project
  3. At this point no one ever checked the code for such fragments (System.out.println) thus most likely we have some other nasty problems ahead.
    1. bug fixes can be trivial but most of them can't be estimated
    2. the IT department of the customer will ask the business to extend the budget sooner or later
    3. if the product is business critical then it will have a new version developed, typically the programming platform will be blamed.
At this point you should understand that there are more than one people to blame for someone's commit. If you think pinpointing the one with SVN blame is the solution then you just don't get it.

And just for clarification: it wasn't me :) I'm just bringing the news about the 300.

No comments:

Post a Comment