Technical Progress and Joel Test

The Joel Test: 12 simple yes/no questions verbalised by Joel Spolsky in 2000 to determine the pain of developing software in some company. Since he wrote them, I have been using them to check companies if to work for a them or not.

In 2003 and 2004, I "checked" several companies during interviews or asked friends about their jobs. Back then I found that marketing and web design agencies scored lowest (1 out of 12), followed by little software shops and in-house development of small companies (2-3, sometimes up to 4). More seriously working software companies usually reached 6. That was it. Only one out of 20 companies scored 9, still not ideal. (Especially noteworthy was a mobile phone provider with more than 1000 employees having only a score of 3.)

In 2008 while looking for a new job, the companies I met were scoring about 9 or 10. I do not have much data to state any facts, but this feels much better than 4 years ago. The question is if there is such a tendency, a technical progress of the software engineering craft, that could be measured by Joel's test? Or is it just my experience telling me where to look for proper work now?

Update 28 February 2009

All Lies

After accepting an offer of one of these companies I found another reason: They were lying! They said they are able to build the product in one step. Well, that's somehow true but only after changing some hundred configurations in different files. And yes, it's also true that they have daily builds, continuous builds even. But nobody is watching the build status until a new release has to be created. That's hardly what I expect from a daily build. So their real score is 6 at most.

JRuby Performance fails in Batch

You JRuby advocates will say it's obvious: I did not use Java 6, did not compile to byte code etc. You JRuby objectors will say it's obvious: JRuby is so sloooow. Probably the truth is somewhere in between and depends on the circumstances. So here is my little story about trying out JRuby in the enterprise...

We have some kind of ETL Loader that collects data into objects before inserting into the warehouse. Depending on the state of every particular instance some value is precalculated and stored to speed up the queries later. (DWH-data is usually not normalised.) Until now these calculations have been spread across the whole import and transform process, which was a real pain whenever something had to be changed. Recently we had to add some new calculation rules and we decided to make it proper: 1) Put all calculation rules in one place and 2) put them all in some kind of configuration file.

As the checks of the state vary considerably, we need a "powerful" configuration language. How about a dynamic language running on top of the JVM? (Which looks like the mainstream method to solve many problems nowadays ;-) In an XML file (boring mainstream again) we have a list of simple JRuby expressions.

<ACTION_REQUESTOR_EVAL>
  <requestor active="true" type="SUPPRESSED">
    <code>$action.suppressed</code>
  </requestor>
  <requestor active="true" type="SPECIAL_CASE">
    <code>['GPDA', 'LIA'].include? $action.name</code>
  </requestor>
  <requestor active="true" type="OVERLOAD">
    <code>$action.overload</code>
  </requestor>
  <!-- all others are normal -->
  <requestor active="true" type="NORMAL">
    <code>true</code>
  </requestor>
</ACTION_REQUESTOR_EVAL>

A centralised component evaluates them in a Chain of Responsibility style.

BSFManager manager = pContext.getManager();
int line = 1;
manager.declareBean("action", pActionData, ActionData.class);
for (ActionRequestorEvaluation eval : getRequestors()) {
   boolean isOfType = ((Boolean) manager.eval("ruby",
      "action eval command " + eval.getType(), line++,
      1, eval.getCode())).booleanValue();
   if (isOfType) {
      pActionData.setRequestorType(eval.getType());
      break;
   }
}
manager.undeclareBean("action");

After adding some unit tests we deployed the loader to the test system. Unfortunately this solution ran 3 times slower than before, taking 25 instead of 8 minutes for 100.000 entries, adding approx. 10 milliseconds per entry. Considering that in most cases 10 expressions are evaluated, that's only 1 millisecond per JRuby call, so it's not that bad. (The numbers were got using Java 5 with BSF 2.4.0 to access JRuby 1.1.3.)

The conclusion is that the straight forward use of JRuby in batch processing (i.e. when called millions of times) does not work. So we had to undo the changes and put the rules hard-coded into the code :-( Unfortunately we had only time to try the "plain" approach. Obviously there is room for improvement, I would like to hear about.

Viewing Dependencies with Eclipse

Dependencies between classes are somehow double faced. Classes need other classes to do their work because code has to be broken down into small chunks to be easier to understand. On the other hand, growing quadratic with the number of classes (n nodes can define up to n*(n-1) directed edges in a graph), they can be a major source of code complexity: Tight coupling, Feature Envy and cyclic dependencies are only some of the problems caused by relations between classes "going wild".

I try to avoid (too many) usages of other classes in my source. But it's not that easy. Consider a class in some legacy code base that shows signs of Feature Envy for classes in another package. Should I move it there? To be sure I need to know all classes my class is dependent upon? I mean all classes, so checking imports does not help. Even if I forbid wildcard imports (what I do), that are still not all classes. Classes in the same package are rarely shown by tools. Even my favourite Code Analysis Plugin (CAP) for Eclipse does not show them.

So here is my little, crappy, amateur Java Dependency View Plugin for Eclipse. Unpack it and put the jar into Eclipse's plugins directory. Restart Eclipse and open the Dependency View.
(The small blue icon is my old coding-logo, a bit skewed.) In the view you'll see all kinds of outgoing references: inner classes, classes in the same package, other classes, generic types and sometimes - a bug in the view.
The plugin was developed with Eclipse 3.2 and tested in 3.3. Source code is included in the jar.

A nice feature, that I was not able to implement would have been reverse search, i.e. a list of all classes depending on the current selected one. If you happen to know how to to that, i.e. how to search for all classes that refer the current class, drop me a note.