Coding productivity

I while back, I read The Mythical Man-Month. The data in chapter 8 of the book (which is by no means recent) points out that the average productivity for a developer, measured in debugged lines of code per year is almost constant.

The interesting part here is that it is constant even when changing languages.

The data compares LOC written in low level machine code and those written in a high level language (PL/I). Because every line in PL/I was on average generating 5 low level instructions, this mean improving developper productivity by a factor of 5.

Fast forward 32 years… and now I’m here wondering if the rule still applies.

I guess the answer is yes, and that’s why everyone is so happy with languages like Ruby and concepts like convention over configuration, which allow you to write less.

But then… Spring must be a huge productivity boost, since it is quite coarse grained. You’re not avoiding code… you’re doing more with less code. Same thing for Hibernate.

Less LOC, more function.

To be fair… this is more related to component reuse (called “buy versus build” in the book) than to higher level languages.

Then there are the DSL (Domain Specific Languages) that are starting to pop up everywhere. Specific high level languages for specific problems (like configuration, business rules, etc…). Those should really cause a big impact in productivity if they can be used in a significant part of a project. I’m under the impression that DSLs are used for relatively small parts of a system (maybe BPEL would be the only one able to have a wider scope).

So why aren’t these new languages/frameworks used everywhere? Why are they not taught at computer science faculties?

It’s related to the intellectual load imposed on the developer.

Lower level languages can do any thing with a reduced set of commands (functions, operations… you name it). The developer needs to know very little thing about the language but needs to figure out how to do every little thing. Just imagine how a simple hello world program would look in assembler.

In the other hand, higher level languages require knowledge about lots of commands and features. Put in the mix a wide collection of extensions (or libraries) and integration with other high level languages, and the intellectual overhead is just barely manageable.

Maybe at this point is where we start creating standards. J2EE is not the best of the options (JSF, EJB…) but is a standard. A developer can learn it and have a pretty good grasp of everything without being overloaded with too much information.

However, most companies are using other kind of tools, like Spring or Hibernate (although Hibernate now can be used with JPA, so it can be seen as a standard). And every project/company uses a different presentation framework (we have plenty to choose from in the java world).

And then there is Eclipse RCP, Grails, Jython… and outside the java world you always need some Bash, Perl (at least Perl regexps)…All this tools make something easier and faster, but they add to the pile of knowledge a developer requires to do his job.

Under this stress, how can we remain productive and still be able to create working solutions in our jobs?

I don’t know. But we certainly do.

And from time to time, they are not only working… they are good!

Appfuse 2.0, sweet!

I must admit that I had never tried Appfuse 1.0 because of my laziness. It required me to download something, install it somewhere and then run ant on it… too many things just for giving it a test ride.

But the new 2.0 version is just a piece of cake. No installation needed. Just use your Maven tool and generate a template project from scratch. There are several templates available, depending on your particular taste.

Let me clarify that, even when I call them “templates”, what you get is a working webapp (you can even run it from the command line, without installing anything else). The webapp does not do much… but is actually good looking and provides a log-in form and user management features (two things you will likely need).

By now, only milestone 2 has been released. Milestone 3 will come later and, at last, 2.0… in “late” 2007.

I expect (time permitting) to dig a little deeper on it… And you should too.

Transparent database encryption

A co-worker and friend of mine recently released a new open-source project. It is called Jasypt (Java Simplified Encryption).

It is focused on simplying the most usual cryptographic tasks (like encryption and hashing) with a plus: it is designed with easy integration in mind.

If using Hibernate, you can declaratively configure encryption for your persistent entities, and it is also easy to manage through spring.

For more information, read the announcement on The Server Side or check the project site.

Logging SQL queries with Hibernate

I’ve just realized that several visitors landed here searching for this information…

Enabling SQL logging with hibernate only requires to use the property:

hibernate.show_sql = true

(more information on chapter 3 of the manual, table 3.3)

However, some preffer tweaking the log4j configuration (this way, they can choose where to log the SQL). Read the comments to know how to also log the values of the parameters.

Hope I helped.

Unit testing, a better way

I’ve already blogged about unit testing with Spring and Hibernate. But it turned out that unit testing is much simpler when it is done the right way.

See for yourself and compare.

Instead of having a test Spring context, I manualy wire the beans in the unit test. Instead of executing against the database, I build a fake (mock?) database… a HashMap. No useless work here (that’s what I try, at least…).

As all the code accessing the database is encapsulated in Accessors (DAOs, if you’d preffer), I can just write a new one for testing, which accesses the HashMap database with an annonymous class. And then, just wire the accessor into the class to be tested:

protected void setUp() throws Exception {
  super.setUp();
  accessor = new UserAccessor() {
    private Map<String, User> users = new HashMap<String, User>();

    public void save(User user) {
      if (users.get(user.getName()) == null) {
        users.put(user.getName(), user);
      } else {
        throw new RuntimeException("Already exists: "
          + user.getName());
      }
    }

    public User findByName(String userName) {
      return users.get(userName);
    }

    public boolean exists(String userName) {
      return findByName(userName) != null;
    }
  };

  classUnderTest.setUserAccessor(accessor);
}

Now I can test whatever I want without a database (which means much faster!).

However, I’ve got the feeling that there should be an even better way. Any takers?