Development
March 5th, 2002
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.
Entry Filed under: SpaceMapper, Software Development
