In 14 March we will have one year since we actually started the coding on
all of the “SpaceMapper” projects, a very difficult one but full with
rewards.

So, I took JMetric
and I did a couple of measurements on mn8. Here are the results:

• Lines of code: 20311
• Statements: 14218
• Classes: 211
• Methods: 2296
• Variables: 981
• Public Methods: 1877

This is just the code, no documentation, no unit tests, just the core java
source files. This was till recently a man/month effort. With the actual
code started only from August, till August I was working on the prototype.

Not bad, I guess.

I only have two features open with
one task in each so I’m really at the
end of a first serious release. It’s not a bad feeling but it is not good
either, it’s exhaustion, accomplishment and scare. In a couple of days/weeks
your secret will be publicly exposed. It’s like having a child and giving
it away to strangers to take care of him.

Enough of this mumbling this is not what I had to say. I was about to tell
you about testing and bugs.

The last two months among closing the remaining features we started
intense testing. What I found is that bugs comes in layers. Three
particular type of of bugs, each type with it’s own schedule.

The first layer is the soft and easy bugs. Plenty of them, quick to catch
and fix. Unit tests are great investment for this layer.

Then it comes the more complex layer. Not difficult to find but a bit more
trickier to fix. Most of this bugs can be catched by unit test and can
easily be kept under control for the future, again through the unit tests.

But then comes the last layer, at the end when, you are really tired and
seek of bugs. These bugs are nasty ones. Very hard to catch, very hard to
reproduce, very hard to understand what the hack is going on. Should I
mention about fixing them? I spent the last two days chasing such a bug,
I’m not there yet, but I will. Sometimes I wonder if it is a good idea at
all to spend so much time for just one bug?

Unit tests won’t help you with these bugs, except maybe after you fixed
them to make sure don’t reappear.

Also was interesting to notice that whoever said that 80% of bugs are situated in 20% of
code was absolutely right. The majority of bugs where around 3 classes which where
extremely complicated. Hard to believe that 80% of the bugs where actually in around 200
lines of code from 20,000. The problem is that when I designed those particular portions
of code I was aware of the grade of difficulty exposed so I tried to code in the way Kent Beck recommends and explicitly
expressing intention. All this by using meaningful names, breaking the code in many
minuscule methods and so on. Still, even if was a lot easier that way to understand
functionality it continues not to be extremely easy.

Another interesting conclusion was that even if at the beginning all of us blame somebody
or something else, always, and I mean always we are the stupid ones, and probably the
debugging time would be reduced considerably if we would always start checking the code
instead of trying to catch what we imagine is happening which almost always is miles away
from what is actually happening.