Release 0.13 and beyond

I have released Version 0.13 two weeks ago and now I plan to put about four weeks into the next release. The next version number is planned to be a 0.25, because there will be some major enhancements, namely multiple diagrams and a new diagram type: sequence diagrams. Sequence diagrams are what I consider the most difficult of the UML diagram types. The main reason for that is that the interaction seems to be completely different than for the other diagram types. The elements are moved like they are on rails (ha, why don’t I call it “TinyUML on Rails” ? Nah, just kidding)

The first step for me is now to make application configuration more flexible. At the moment, I am pretty involved in my “programming for a living” activities, so I need to do something which is less demanding to relax. So this week is just about offering different ways to deploy TinyUML. I have put it in an Applet first, I haven’t seen that anywhere else so far (even though for Java that is a pretty obvious thing to do), the other configuration I added is Webstart. Being able to run on a variety of platforms and configurations is generally considered as a sign of quality, for me that is a reason to implement desktop applications purely in an object-oriented cross-platform language (e.g. Java, Python, Ruby) and to abandon native code completely. So far, I haven’t missed it, especially with Java it is difficult to find a reason why one would have to use a native library.

I also decided to introduce maintenance branches in my process now that the software has become more complex. By this way, I can release fixes very quickly on the release version without affecting the development (or so I hope).

Another change is to abandon the idea of using Mantis as the tracker tool and to entirely use the sourceforge tracker. While Mantis is a great tool, I believe it is easier to have the tracker hosted within the sourceforge environment.

First experiences with Ohloh

Today, I discovered a website called Ohloh. This is a service that evaluates Open Source projects under certain criteria. I decided to try it out and registered both TinyUML and ZMPP there.

After some time, an information screen appears, listing the data it determined for the project. The summary for both looks like this:

• mostly written in Java
• well commented source code
• short source code history
• only a single active developer

Interestingly, the scoring whether code is well-documented is dependent on the average for a programming language. A value of 30 % would be extremely high for C, for example. The website determines the following values for average comment-to-code ratios:

• Java: 35%
• C#: 24%
• PHP: 24%
• C/C++: 20%
• JavaScript: 18%
• Ruby: 16%
• Perl: 14% (!)
• Python: 12%

Seemingly, for Java projects, this average is usually very high, much higher than for other languages. As I already expected, the value is much lower for Ruby and Python, probably because they are more easy to read (I could not get the values for Groovy, but I guess it would be in the same ballpark). Big surprises for me are Perl and C/C++. For any non-trivial software project, 14% or 20%, respectively look way too low.

The reason for the higher average on Java projects is probably the wide availability and acceptance of automatic code review tools (such as checkstyle and PMD) among Java developers, but it is only a guess.

My personal opinion is that larger C/C++ or Perl projects could in fact benefit from more code documentation, that’s what pod and doxygen are for.

Another interesting feature is the calculation of project costs, which is seemingly completely dependent on the Lines of Code metrics. For TinyUML it determines 14415 LOC and an effort of 3 (!!!) person years. While the 14415 Lines Of Code measured might be correct, I am really surprised about the estimated effort of 3 person years (another thing would be the average salary of 55000 USD/year – I think the salaries for software engineers here in Washington are way higher).

According to this, the average productivity of a programmer per year for 55000 USD is less than 5000 LOC. While the LOC does not say anything about the usefulness or quality of the software, this number seems terribly low for average productivity, assuming people working full-time on the project.

On the other hand, it does not account for different programming languages, it usually takes much more effort to write an equivalent program in C compared to Java and projects written in scripting languages tend to be even smaller.

In a comparison of KFrotz and ZMPP which are both implementations of the Z-machine with a similar feature set, KFrotz has 35204 LOC and ZMPP 18035. Still not the whole truth, Ohloh counts comment lines and test code, which account for two thirds of the overall ZMPP code, so it is actually only 8840 NCSS.

Test code is a factor that might make projects difficult to compare for Ohloh. Of course it contributes to the overall cost and effort for a project, but not directly to the functionality. That would be an interesting additional feature for the future, since more and more projects adopt automatic testing.

Still, I think, Ohloh is an interesting way to look at a software project and there sure will be some improvements in the future.

Cait Sith milestone release

After two weeks I got the Cait Sith release ready. Looking back, I am surprised that it only were two weeks, there was so much stuff, that I put in and changed during that time and until now, this was definitely the most challenging release cycle. This is why I also decided to increment the version number to 0.12 instead of 0.11.

The editable connections were a pretty hard piece of work and there is still room for improvement. For now, they work good enough for me. I now added context menus, so there is quicker access to the functionality. There are a lot small things that were put in, things that are barely noticeable, but improve the overall usability.

This time, I also took the time to test the whole system a little more thoroughly. It took about two hours including fixing the bugs that I discovered. I noticed that I should do the feature freeze a little earlier, dependent on the amount of functionality that I put in. I just could not stop putting in new stuff.

I also noticed that the two weeks release period was appropriate, probably too short for the feature set. Next time, I will choose either less features or more time.

Looking at what I can do with the system now, I am pretty happy with the progress. TinyUML also passed the first usability test by my wife: She created a diagram without any knowledge of my software or UML diagrams. She either is incredibly smart or the software is simple enough to understand. While I hope that the latter is true to a certain degree, I have to admit that my wife is indeed pretty intelligent.