Heikniemi Hardcoded

He, Bugzilla, is misguided (and on Open Source QA)

Dennis Heuer posted an article called I, Bugzilla on OSNews. His essential claim is that Bugzilla makes life hell for open source users by making it ridiculously hard to get support. As the numerous reader comments on the article point out, his gripes are mostly about annoying personalities around OS projects, not the software itself. Not that I didn't agree with some points though; the default Bugzilla UI is a bit frightening. Luckily it is being worked on.

However, the article and its reader comments do raise several interesting points about open source project QA. Some readers claim that anybody creating OS software has a moral obligation to support it, and "Everybody here is a volunteer and under no obligation to fix your bug" is just bad behavior. If the quality and bug tracking of OS software is close to your heart, I suggest taking a quick read.

As for my personal opinion, even though I understand why people are inclined to expect some support even for free software, I find the ability to "fire-and-forget" code a very valuable characteristic of modern Internet-based software engineering. Take my Bugzilla contributions for example. If I had the moral obligation to support every line of code I've ever written, I just couldn't (and wouldn't) squeeze the time to implement any features that I don't need myself. The risks would be too big. The lack of permanent responsibility is what allows me to use my occasional spare time to do work that helps others.

Comparisons to freeware/shareware of the 90s aren't justified. The modern OS movement is the engine for huge products (Mozilla, Linux, OpenOffice...) where the touch of personal responsibility can never be what it used to be for all those euro calculators years back. The fact that much of the world's computing runs on software without a guaranteed support is somewhat frightening - but then again, am I any less convinced by the commercial apps?

Be it as it may, blaming the OS developers for not supporting their code forever isn't going to solve the issue. If you personally feel obliged to support every free code line you've given others, you have my respect. I try to be as supportive as possible, too. But when (not if) I fail because there's a life outside open source, I can't afford to feel too bad about it. If I did, it would increase the social cost of OS participation enough to stop me from doing it. I believe the same goes for a fair number of contributors.

Live bookmarks bring RSS to your bookmark folder

Firefox 1.0 preview release is out, and live bookmarks rock. If you don't know what they are, take a look at the previous link and the image to the right. Simply put, it's an RSS reader inside your bookmarks folder.

I need to think about this a bit more, but I believe this technology offers some great possibilities. Distributed bookmarks are just the beginning.

Loose thoughts on code documentation

Anatoly Shalyto, a professor at Saint-Petersburg State University of Information Technology, Mechanics and Optics recently published an article about Foundation for Open Project Documentation. If you're interested in reading another set of philosophy about the importance of documentation in general, go ahead and read it. I didn't find the article itself very interesting or evolutionary, but it did give rise to a couple of thoughts.

First, I can't remember when I last saw a project that had a really admirable quality of documentation. If the user manual and installation instructions are well written, projects usually get praised... until somebody has to pick up the development ball after a three-year break during which the original code authors have switched jobs. Technical specifications are often limited to the few structural diagrams drawn during the analysis phase and a hastily sketched DB diagram/document that's roughly maintained throughout the project. Who said documentation is only for customers (or worse, end users)?

Second, I can't remember when I last saw a developer with a really documentation-oriented approach to software engineering. By "documentation-oriented" I refer to the desire (and discipline) to make sure that the brainwork is actually recorded in a reusable form. Writing good, readable code is an important step. Using proper design patterns helps, too. But does all this produce a really durable solution? Not without documentation. Not even the geekiest developer is better at reading C++ than plain English (or whatever your preferred language is).

Code-technical documentation - by which I mean documenting very simple issues such as namespace/class relations, chosen algorithms, design patterns and so on - has lately been very close to my heart. I'm certain I'll be returning to the subject sooner or later. When I look at f.e. Bugzilla, I see a huge need for somebody to explain the code structure in both diagrams and words. If we had a proper technical documentation, developing BZ would be so much easier for new people - and we'd probably have less bugs as well.

Until I've formulated another rant on some practical approaches in code documentation, I'm sticking with this motto: Mistakes in Word are cheaper than mistakes in Visual Studio. Feel free to substitute your favorite documentation/code editors. And I'll finish off with this citation from Shalyto's article: 'One of the pioneers of the aircraft D. Douglas said once - "when the weight of the documentation becomes equal to the weight of the airplane, it is ready to fly", and A. Martin affirms, that the documentation for the famous Boeing 747 weighed more, than the plane itself.'

Spam-related, part 2

A while ago I wrote about spam filtering in MovableType. It turns out that the blog spamming bots are a bit more advanced than I expected. A simple hidden field (even with an html encoded value) didn't cut it - apparently the bots have gotten to the point of actually parsing the HTML, at least to some extent. I still believe they're hacky at best, so throwing in some SGML anomalities will probably curb them. Too bad browsers are hacky too - it's going to be another balancing run to do something that browsers will interpret correctly and spambots will be mislead.

Until I have the time to manipulate my blog templates again, I installed MT-Blacklist which seems to be quite a good temporary solution.

To change the subject to email spam, CodeProject's recent article called Avoiding spam-bots is a good example of fixing problems the wrong way. It's got exactly the same idea as I described below: Try to store data in a form that's unreachable for spambots, but that can still be useful for the normal user (browser or the human). In the example, Javascript-based encoding is used.

It hurts to read the comments: Most readers applaud the solution, but apparently without understanding the implications of requiring JS in the first place. Oh well, it's going to bite them - or their possible customers - at some point. At least they weren't talking about embedding the email address into an custom generated image.

Still, I agree spambots are an issue. Personally, I've stopped caring. I just publish my email address freely and focus the effort on filtering the spam at my mail client. So far, the combination of SpamAssassin and Thunderbird is working remarkably well. It takes me a few seconds every day to wipe the couple of spam messages getting through, but it's better than requiring everybody wanting to contact me to either have JS or manually fix my email address. Btw, the filtering ratio is at 95-97% currently, so I'm pretty happy.

What do you mean "you can't"?

Every now and then I come across a situation where a person gets asked to do something, usually a work assignment, and he replies resolutely: "I can't". The voice inevitably conveys the lack of desire for the task. But what on earth you mean you can't???

Ability to do something is an interesting factor in human behavior. At worst, it goes like this: Unless you think you can X really well, you can't X. Not at all. If you're asked to X, you refuse. Well then, if you think you can X rather well, you're insanely smug about it. At this point, your skills aren't at the level of your bragging. If you spend some time with people who really know X, you probably degrade to the level of not being able to X at all.

Most of the people aren't really that bad, but surprisingly many make themselves look like clowns by making foolish statements on their abilities (or lack of them). But what's worse, people who stop at their "I can't" send out a really negative signal.

A book called The 12 Simple Secrets of Microsoft Management describes quite a few interesting management aspects from the Microsoft world. One of the key points is about recruiting smart people. There's an interesting paragraph on job interviews:

"The questions also search to see if the candidate can think. One of the old favorites at Microsoft was to ask how many gas stations there are in the United States. The interesting part was not the final answer, but how people went about solving it. Some candidates would give this question only 30 seconds of thought and then say they didn’t know. No further thought or attempt. At that time it didn't matter what else they could do. If they were incapable of turning on the brain, they were not good enough."

While Microsoft's recruiting practice certainly isn't a universal standard, it's safe to say that qualifying to work at MS means you'd probably qualify for most of the other tech companies as well. Regardless of any recruiting issues, "turning on the brain" is becoming more and more necessary as IT solutions get increasingly complicated. Saying "you can't" and stopping there essentially means you're going to perform routine tasks only. That's fine, but you don't belong in IT development then.

Spend some time on introspection. Learn to know what you can and what you can't. Keep people's impressions on a realistic level. If you're not familiar with something, say it - but don't let that stop you from doing your best. Few things are more motivating than lifelong learning.

Ps. Unless you already read JobsBlog at MSDN, I suggest you take a look. It's written by a couple of Microsoft recruiters and provides pretty interesting insights into tech jobs world. Again, from a Microsoft perspective only, but much of the psychology applies for everyday life even outside the IT world.