HCoder.org

Too funny not to share :-)

I always thought that Smalltalk would beat Java, I just didn’t know that it would be called ‘Ruby’ when it did.

From La Cara Oscura del Desarrollo de Software.

Lately I have been thinking a lot, not to say “obsessed”, with the big picture. I can’t but wonder if that is a general IT industry problem, that big picture. I mean missing it.

My current theory is that computer work is just too hard (or tools not advanced enough?), and there is too much pressure and too hard time constraints to allow people to step back and think about the big picture from time to time, to make sure everything makes sense.

And perhaps that’s why you hire and have QA people, perhaps that is the real purpose of QA. At least I feel that now. I mean, what’s the use of something that has a high “technical quality”, if it just doesn’t make sense? That is actually a big part of the quality, “making sense”. Because of that I’m starting to feel like my job is being a developer that does important things that “nobody has time to do”, because they’re too busy fighting with details. Not in the sense of a “manager”, but in the sense of some “responsible” developer. It’s a really strange job position I think :-)

It’s really hard to measure the impact of good QA in a software project, but I’m sure that is high, probably higher than people use to think. For me, thinking about software projects without QA is a bit like thinking about programming without a Version Control System: I wonder how I had done it in the past, and feel really unconfident without it. How many projects have failed (both from the resources and goals point of view, and from the business point of view) for not having good QA? How many projects have been delayed, or even cancelled, because they lacked someone caring about the Big Picture?

EDIT (2008-5-18): I have disabled comments in this post due to insane amount of spam. If you want to comment, please comment in some other entry :-/

As I said earlier, now the fun stuff begins :-) I have been working with dhelp these days, and there are a couple of things I have changed already:

• I have dropped support for the dhelp-specific .dhelp files. Now I just use the doc-base information directly (until now, doc-base had to convert its own format to dhelp, which was a bad things for several reasons, one of them losing important information in the process).
• I have changed the indexing code so it now indexes the actual documentation content, instead of the documentation directory generated by dhelp.
• I have rewritten most of the HTML used in the searches and in the documentation directory so it’s nicer and easier to modify (e.g. no more <font> or similar obsolete tags).

While working on the indexing changes, I have been playing with swish+++, an indexing engine. Seems really useful, although some options are not that obvious, and I haven’t been able to use extract++ to extract the text according to the file format (e.g. skipping HTML tags in HTML). I’ll keep trying…

Hopefully, the package will be ready for release in a week or so…

I finally uploaded dhelp to unstable, and everything went almost surprinsingly good. The only bugs reported so far are #448211 and #447789. The first one was a silly mistake made by me, in some translation files that aren’t even being used now (that will change in the near future). The second was a bug exposed by dhelp, but actually in another package (libcommandline-ruby, which is funnily enough also maintained by me, and it’s already patched and pending upload).

So, now that the package is uploaded and we’re using a sane implementation for dhelp_parse, I can start doing fun stuff. Right now I’m mostly fixing more bugs, but I’m also implementing new features and talking to the doc-base maintainer, to improve the integration between both.