SGrottel.de

Drat! I wanted to write a post each sunday. Oh well. I will try to minimize these slips and I will try to catch up as quickly as possible.

The news: The TheLib project now uses a Subversion repository!

After Mercurial failed to proof its value, our eagerness for experiments had dried up. We thus switched to a system we knew it worked and how it worked.

Of course, there are countless projects happily working with Mercurial and, of course, there are countless good reasons why everything would be better using Git. To be honest: I don’t care.

Some time ago I fret about Mercurial. My opinon on that has not changed since then. The conversion tools are still ridiculously bad and the fact that no development group is interessted in SCM protocol interoperability is pathetic.

Nevertheless, I want to talk about Mercurial again. During the last weeks I worte some (scientific) texts together with several co-authors. These texts were controlled by Subversion repositories. I have to say: It did work perfectly!

Additionally I am working on a small (or maybe medium-sized) code project. There I create a library which is used by several persons by now. This is part of my working project VICCI. For reasons out of my control there is only one single subversion repository for all subprojects in VICCI and there is a globally dictated directory structure making it impossible to set up the usual “branches” and “tags” subdirectory for my project, because of external dependancies. This is … painful. I really should make some changes of the API of my project, but as it is now, I cannot do this without either not commiting unfinished code for some time or without breaking code of some of my colleagues. Of course there are solutions which only break everything for a very short time and which make everything better after that. But it is amazing how difficult it is to change something as soon as the group of people involved has a certain size. Whatever. With the current state I will not be happy.

A nice technical solution would be multi-protocol interfaces to repositories: i.e. a hg- or git-repository with interfaces for all: hg, git and svn. This is possilbe (see my conversion-tool-rant). Just, no one is doing its. *sigh*

It is again time for posting? … Time flies.

During the last days I kept wondering about software engineering. Somehow it is quite unsatisfying. Programming is a hard, tiresome and longsome work. I takes foreever. A program with the complexity of “Hello World” requires, if we are honest, roughly one week, I believe. No kidding. Of course, you could code this in 10 minutes, but if the programm needs to do something as absurd as processing input to generate output, then there will be countless details. Every one claiming “Whatever, I am gonna make it in an instance” makes himself/herself unbelievable and disqualifies himself/herself for working on larger projects. Sadly, this is still true for myself as well. I still tend to dramatically underestimate the time software needs.

The worst thing, however, is that you will not see the software consuming time. You will put weeks and months into a software. And looking at it from the outside you will not see any progress. Of course, at one point-in-time there will be a “click” and almost everything starts working, but it is a long way there.

So, how about RAD? My experience with RAD is that it is ok for small GUI-Programs. However, if the planned functionality is to large or to complex you quickly reach a point in RAD where it gets harder and harder to introduce the missing functions. You complete like 80% and then you have to fight for every new function to work correctly with the rest. The only way to avoid this is to produce a good foundation for your software. And there we are again: writing software which consumes a lot of time without providing early visible successes.

Well, whatever. This is the way it is, it seems.

Did I complain about software development, again?