Yesterday was somewhat less active coding day, still focused on bugfixing the BT module. I still have some issues open related to cross-file hashing, which is the reason why I'm not making new builds just yet. Still, a number of bugs were fixed yesterday, for example we now correctly handle torrents exceeding 4gb size, also I finally figured out why some clients were sending chunks of length 0 always - apparently I had forgotten to take the remote client's chunk-map into account when selecting chunks to download. Furthermore, as I had split the request-generation code (rather resource-intensive currently) into 4 separate functions the day before, yesterday I was able to eliminate one of them completely - getLeastUsed(), and incorporate the logic in there into getNextPartial(). getLeastAvailable() already takes use-count into account, so we won some cycles there.

A few days ago (on 15th), Hydranode became 18 months old, which was also the original estimated development time for the project, I figured this is appropriate time to do some statistics on the codebase, to see the amount of code produced during this time, development speed and so on. So here's the details.

Total lines of code:      53223
Lines of executable code: 35783
Lines of comments/docs:   17450 (32%)
Executable code per component:
 - hnbase library:         7673
 - hncore library:         7437
 - edonkey module:         8292 (excluding the crypto code)
 - hnshell module:         1913
 - bittorrent module:      3319 (alpha status)
 - http module:            2036 (beta status)
 - core/gui comm module:   1011 (pre-alpha status)
 - ed2k/kademlia module:    782 (pre-alpha status)
 - directconnect module:    683 (pre-alpha status)
 - email notif. module:     122 (beta status)
 - ftp module:              281 (pre-alpha status)
Average +code/month:       2901 ( 1987 when excluding documentation)
Average +code/year:       34812 (23844 when excluding documentation)
Development time:     18 months 
 - 1 fulltime dev 
 - 1 parttime dev
 - 3-4 random contributors
 - 5-10 active testers
Average ~50 checkins/week in SVN repository (tops at ~70)

To give you a comparison value, aMule v2.0.3 is 93547 lines total, out of which 22847 lines (24%) are comments/documentation. eMule 0.46b is 142039 lines total, out of which 20820 (14%) lines are comments/documentation. eMule is roughly 46 months old (started early 2002), which means 3087 lines/month, 37044 lines/year development rate. aMule is based on eMule codebase, so time-wise calculation can't be done there.

What does all this show? First, we see that when we include documentation in coding-speed calculation, Hydranode is near eMule, and considering Hydranode has 32% documentation compared to eMule's 14%, we see that writing documentation is a considerable hit for development speed. We can also see that since the creation of LMule (the first eMule linux port, on which aMule is based upon), eMule has evolved faster than aMule, but aMule has become more documented, so we can deduct that aMule developers value documentation, and thus code quality over more features.

But, we'r getting off-topic here, we were looking at Hydranode's statistics. We can see that about one-third of the current codebase is in base and core libraries, which is good - large amount of code is shared between modules. eDonkey module, being the oldest and most feature-rich is naturally the biggest module, even passing core library in size. Bittorrent module, however is catching up fast, altough I estimate BT module will cap at around 5000 lines of code, since the protocol is lot simpler (and DHT implementations, both Mainline and Azureus ones, will go to separate modules). Http module, despite sounding really simple and straight-forward when you think of it, is still a considerable amount of code, due to a number of features, such as proxy, usernames/passwords, etc support.

In general, it would seem that we are roughly up-to-par, perhaps only slightly behind, with development speed compared to other projects. I'm aware of the fact that eMule actually has three active developers (maybe more that I'm not aware of), aMule has 3-4 I think, and this is not counting external contributions, but I don't think breaking the statistics up for per-developer is worth it. Also, neither eMule nor aMule have the strict 80-chars-per-line limit as Hydranode has, which affects the statistics - if Hydranode was written in eMule-style (I'v seen 200-character lines in emule code), the total lines of code would be less, thus indicating even slower development speed. Some might argue that Hydranode is much more complex application, but that's not true - complexity is relative and cannot be measured. What may be complex to one developer may be easy for other developer, and vice versa. Just as we have really complex issues with, say, BT virtual file wrappers, eMule devs have really complex issues with some wierd MFC control not doing what they want it to do - solving complexity always takes time.

All in all, while it seems really odd that a project has gone on for 18 months, and is still in it's 0.1 release series, from raw statistics it becomes apparent that we'r actually quite on-track with development speeds, compared to other clients. The illusion that Hydranode is still very young project comes from the fact that other projects have become widely usable a lot sooner, for example eMule got it's 1'000'000th download just after 4 months since the project was registred on SourceForge. This can be explained by the fact that the other clients have user interfaces built-in (or engines built into user interfaces :)), which means they became usable to wider audience lot earlier in the development process. However, with Hydranode, we have one fully-featured network module, and are developing second large network plugin, yet have no user interface to speak of, the latter of which creates the illusion.

Madcat.