Agile Grenoble : Le programme est la !!!

Leave a comment

1/8 Mister Build has problems

1 Comment

Mister build is part of a team, having some issues on its project. It was difficult for him to name/qualify its issues, so he decided to define a smell list.

Bad Smell list for a build

Not Automated

  1. Do you have a problem if   your build server is down ?
  2. Do you use a build script different for the developers boxes  ?
  3. Does your build is working on some computers but not on the other ones ?

Not Deterministic

  1. Do you have some resources not packaged in your application ?
  2. Does building twice the same code version, with the same inputs, produce a different result  (version number, … ) ?
  3. Do you use a build script different for the release ?
  4. Does your build ran on two computers produce something slightly different ?

Not Scalable

  1. Does compiling two libraries at the same time on the computer, lead to a failing build ?
  2. Does compiling trunk and a branch at the same time on the computer lead to a random result ?

Not Simple

  1. Does your setup is difficult to maintain ?
  2. Do you have some developers not able to update the build mechanism ?

Highly Coupled

  1. Does changing your source code repository will cost you some (too much) money ?
  2. Does changing your binary storage will cost you some (too much) money ?
  3. Do you have conflicts between your IDE and your build process ?

Bad Execution time

  1. Does your tests run time is too long ?
  2. Does the build take too much time ?
  3. Does your build time take time because you need to package for several environment ?
  4. Does your build time is linked to the number of environment you deploy on ?
  5. Does your build time is linked to the number of  language of your application ?
  6. Does your application used several programming languages, and you don’t know how to link them ?

Bad Dependencies management

  1. For some libraries included, do you have no clue where they come from ?
  2. Do you have a library , you don’t know the version ?
  3. Does your configuration files are included in your libraries ?
  4. Does some dependencies among your modules are out of control ?
  5. Is there any transitives dependencies you don’t know ?
  6. Do you need to change your setup generation, each time you change a dependencies ?

Not Helpful

  1. Does your code contains some bugs ?
  2. Do you have a developer not using the same coding practices than the rest of the team ?
  3. Do you have a developer not using the same coding standard than the rest of the team ?
  4. Do you have a developer frightening of doing refactoring ?
  5. Do you have a developer who don’t know (don’t have a vision of) the quality of the code he work on ?

If you answered yes, to one of this question, you have a problem like Mister build. In the next posts we’ll see how a simple and automated build process, following less coupling rules, coupled with a continuous integration framework can help you.

As mister build answered yes to some of the questions … he will stay as a pedestrian for some more days …


Code quality

Leave a comment

I’ve not post for some time, i was quite bust to set up some CI / metrics tools on a new project.

This raise me some questions / comments.

1) Complexity of the tools

When you read (even in my posts) it’s simple …  I’ve forget a bit the ‘open community’ and in its bad aspects.

Let me illustrate a bit. I am working in a team using mainly Java / Php.

So, using standard tools :

  • Source revision control : svn
  • IDE : eclipse
  • Build : Maven
  • CI : hudson

So, up to now, everything looks fine. I used to use some static code anlysis, in order to know the code quality :

Jdepend, PMD, findbugs, Javancss, cobertura, sonar, Coverity, …

So, nothing really exotic/fancy and most of them are ‘classical’ static code analysis tools.

So,  doing  my ‘Yoda’ show, i’ve encourage the team to use them as soon as possible in their development process so in the IDE.

I’ve plug them in their pom file (maven configuration file), update my hudson installation to have the trend, ….

AND … you know what …. 6 tools,  16 versions needed, because of incompatibility in maven, hudson,  pmd, ….

1 tool , 4 plugin needed …. most of the time just to parse an XML file, or to draw a simple curve with linear data …..

What’s a mess ! where is simplicity ? easy to use ? why coupling a CI tools with build specific plugin ??? why mixing build tools with Source control tools ???

Why not keeping the principle of less coupling to build/CI/static code analysis tools ????

Doing dcode is important, but application design should not be forget.

2) the second point, is some comments : it’s expensive to fix issues …

How can someone justify that fixing an issues at developing time … 5 .. 10 minutes … is more expensive that discovering the issue in production (something like 1$ a minute ? ) , requiring some dev again, some QA, some deployment …..

Of course, the bug may never be seen in production …. for how long ?  Don’t forget the Murphy law : if you can have a problem, you’ll have it !