Release 0.13 and beyond

April 27, 2007

TinyUML as Applet

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

April 21, 2007

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

April 9, 2007

Cait Sith screenshot

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.

Cookies for Geeks

April 5, 2007

When looking for food at the cafeteria next to my office, I discovered a new cookie: Papa Giki, and since I am a “geeky Papa”, I had to try it out. According to the information on the cookis wrapping, it is a heart healthy cookie. Ya, whatever – it does taste great ! It is a rather soft and moist cookie, the raisins in it are also very soft. The fact that it contains german chocolate and is produced here in Washington State makes it even more attractive to me 🙂 Maybe they should think about wrapping more than one together, that would reduce packaging material. As a traditional german treehugger, I had to get used to the american way of using tons of wrapping and packaging material, wax-coated cups (I was never aware of that until I drank hot water out of one, blah !) and styrofoam dishes.

Yesterday’s efforts to improve on progress on rectilinear connection editing was very fruitful. I made one very useful experience: When simulating a user interaction with a JUnit test, I could not reproduce the errors I was getting when I did the same with the mouse, even when I set what I knew was the error-triggering conditions. The reason was that the bug did not show on the first even – it showed on the second one. I finally got the error when I simulated the user interaction more closely with a stream of events rather than just sending a single one. As Kent Beck says “a failed test means progress”. Absolutely true. It you can reproduce it, the work is half done.

Equipped with the new “drag simulating tool”, it was straightforward to add new tests. I haven’t yet got all the points that I consider to be included in that functionality, but it is quite stable, I know why it works (it’s in the tests)  and so far, it “feels” promising.

Unit testing and tracer code

April 4, 2007

There are moments during development where you realize some things are not that easy, here is a result I achieved experimenting with rectilinear connection editing earlier today 🙂

Rectilinear bug

Here is what I really wanted to do:

Expected result

It is clear that it is a good idea to create a test suite for something as complex as rectilinear editing. When it comes to an interactive application, you often reach the limits of test-driven development. In particular, how do you express the tests about how an interaction should work, if you can’t imagine it ?

Therefore, if I want to design an interaction, I usually do “explore-first”, which means to write tracer code, like in the above example. It helps me to explore how to write the code and/or the tests when I have absolutely no idea. It is not a prototype in the strictest sense, since the code has production quality (or what I consider to be production quality) from the beginning. I just can’t write prototypical code, which for me is a good thing, because once I have fleshed out the functionality, I am practically finished.

Sometimes you have to scratch and bite to impement a feature. This is particularly true for client applications, where you can lose yourself in the details (now I am happy not to have used AJAX, I probably would have lost myself in Javascript 🙂 ). I am now the second day into this feature and this one turns out to be even more complex than I thought. Granted, I could just have ducked away, because rectilinear connections can be created using the generic connection type. That’s exactly what I don’t want. Rectilinear connection editing is a useful feature, because it let’s the user create this particular connection style with fewer interactions than the generic way would do.

This is also an example that even though the general advice is to tackle the hardest problems first, that this is not always possible. In this case, I needed to have the basic abstractions available and get the understanding about them in order to design the feature in this context. Often the understanding of the system in development has to grow before more difficult tasks can be executed.

Even though I could probably hack it in until tomorrow, I would not be happy without the tests in place. I take a rather liberal approach to unit testing, but in this case, I insist to have a test suite. So I will need to push my release date to next Monday. I am sure that these additional four days will result in higher quality.

Editable connections

April 2, 2007

I decided to stretch the release periods from formerly 7 days to 10 to 14 days. I’ll use the longer time frame either to tackle harder problems (such as connection editing and nesting) or to include more features.

This release cycle, there are only two features, which I consider important, but a little more difficult: Multiple selections and editable connections.

As expected, multiple selections was indeed very simply implemented using the Composite pattern, with that out of the way, the editor feels much more natural and some code cleanups could be applied on the way.

I am now seeing that editing connections is a comparatively difficult feature, so I assigned five days to get that right for both simple and rectilinear connections. I’ll use more if I need to, because I want it to be both sufficiently clean and usable. To illustrate the idea, I have created a package diagram with a few dependencies where I have edited the connections, with editing, I mean to create new control points, so that connections can be drawn a bit more flexibly.

Editable connections

As shown, it works already for connections which are not rectangular. This is the easier case, rectangular connections have a few rules to take care of.

I originally planned to include package nesting in this release, which is another nice feature with a good learning effect. It does not fit for the current release time frame but I consider it very important, so I moved that to the 0.12 release.