The marketing / evangelizing teams of NetBeans are very quick to respond to any obscure feature reportedly missing from the latest milestone drops of NetBeans 6.0, which usually involve arcane keystrokes requiring two or more hands at the same time. Every once in a while (about once every two-three months) I honestly try to switch to NetBeans for my home development (at work it’s not an option since some of our tools are developed as Eclipse plugins).

One of the best posts on “Joel on Software” described Microsoft’s strategy to compete against the(n) market leader in spreadsheets – Lotus. According to Joel, the tipping point was the introduction of “easy switch” feature into Excel. Not only you were easily able to import an existing Lotus spreadsheet, it was extremely easy to export your Excel back into Lotus. This gave people a sense of security in trying out the new product – if i’m not satisfied, i can always switch back to the environment i already know. And since Excel came packed up with a lot of advanced functionality, people actually never switched back.

Fast forward to NetBeans vs. Eclipse / IDEA / JDeveloper competition. It seems that the evangelists are focusing on the wrong angle. Showing me how to do something in NetBeans when i know how to do this in Eclipse (especially when i know most of the shortcuts by heart) won’t make me switch to NetBeans. What you can do is to let me point to my existing project and not fight me along the way when i want to run it. What do i mean?

One of the main selling points of NetBeans is that it’s Ant-centric (whatever that means). So what happens when i want to import an existing project? NetBeans provides an option to have it as a “freeform” (or something like that) project, which doesn’t allow right-clicking on a class and running it. I have tons of test applications that i need to run, and under NetBeans i can’t run them if i don’t create a new project. And if i create a new project, i’m stuck with tons of ugly and NetBeans-specific Ant tasks that use custom namespaces and what not.

I don’t want that. I don’t want the IDE to fight me. Not when it wants to win my developer heart. I’m OK with Eclipse. Maybe i’m missing a lot by not switching to NetBeans, but the initial barrier for existing projects it too high for me. I want a project that is portable across IDEs. I want a project that my users can check out from CVS and build from the scratch when all they have is a JDK. And that they can do it when the Internet connection is down. I want (at least a false) sense of security that i can always go back to Eclipse. At the present stage (tried 5.0, 5.5 and various milestones of 6.0) i don’t have it.

Time and time again i reach the same conclusion – having bugs is good (if not great) for your project. And before i start explaining the reasons why, you’re welcome to read Joshua Bloch talking about why we will all have them (even if you’re “the best” and not “the worst”):

We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are great. Static analysis is great. But none of these things alone are sufficient to eliminate bugs: They will always be with us.

So, let’s start:

1. It shows that you’re human. We all make mistakes, and it’s only human to deny that. But if you just make an extra effort to acknowledge this and listen to those who know better, you project will benefit greatly.
2. It opens the dialog with your users. If you’re quick to fix it, you will have established a great relationship with the user that reported that bug. He will see that his time in reporting the bug was not spent in vain. The faster you do this, the better for you, your users and your project.
3. There is no such thing as bad bug. You might not like the core APIs, but people are using them. Adding documentation might be annoying, but if your users get lost, they will blame you and choose some other library. And every once in a while you will learn a thing or two from your users.
4. It shows that people are interested in your project. Not only that person downloaded and used your code, he also went an extra mile in writing you a mail and describing the problem. To ignore this is at least insulting to that person. The same applies to accepting bugs only through the project tracker. If people choose to write personal e-mail, respect that.
5. Fixing a bug can (and will) establish professional relations with other developers. You might (and will) get preferential treatment when you find bugs in their libraries that you’re using. Your request to add new features might (and will) get preferential treatment as well. But don’t expect that people will recognize you when you go to the neighborhood grocery store.

I could go on and on, but you get the idea. And last, but not the least – i am proud to say that there hasn’t been a single piece of code that i ever wrote that didn’t (or doesn’t) have a bug. If anybody (including myself) tells you different, he’s a liar.

Every once in a while (and lately, more and more often, as can be seen here, here and here) you see blog entries saying that the best developers are severely underpaid. You start reading through these entries, and they say that the difference between the best and the worst programmers is anywhere between 5 to 28 times. An implicit conclusion is left to the reader – why aren’t the best programmers getting 5 to 28 times as much money than the worst programmers?

I can’t help but think that these entries are very popular because of the Dunning-Kruger syndrome which postulates that a person with little knowledge isn’t aware of how little does he know. If this is true, that would mean that every (yes, every) reader of such an article will see himself in that “best” position. The position where he should be earning 5 to 28 times as much as he is earning now (the higher the number, the better the feeling should be).

But let’s look at it from another perspective. Instead of paying you (as “the best”) five times as much as you’re currently making, let’s pay the others (as “the worst”) a fifth of what they’re making now. Suddenly, all the “others” are gone (the average salary in our field is still much higher than the average in many other professions, but not as high as that). What does it mean to you? That you will be doing all the other stuff that was previously was done by the “others”. If you were truly the “best”, most chances are that previously your boss tried to give you better (more interesting, more challenging, more rewarding) tasks. Of course, every once in a while you get stuck with boring and repetitive stuff (especially if it’s your first position), but if you’re really the “best”, you will get better tasks. But not when the “others” are gone…

So, if you don’t like your current place, start looking elsewhere. If somebody is interested in you, and you’re interested in them, make the move. If nobody is interested in you, take a hint. And be happy that programming is still one of the rarest areas where you can have a very satisfying job that pays well.

“Pushing Pixels” is proud to present the “Web X.0 trends” report for June 2007. We have used the latest tools (*) to follow the trends of Web 2.0, Web 3.0, Web 4.0 et alii. The reference point for the current report presented data on world-wide references to various stages of Web X.0 on October 10, 2006. The latest data has been collected on June 25, 2007, which represents the span of eight months (literally ages on WWW).The first column refers to the number of “Web X.0”. The second column shows the number of global references (*) to the corresponding version of Web on October 10, 2006. The third column shows the number of global references (*) to the corresponding version of Web on June 25, 2007. The last column shows the trend in percents.

The following chart shows At-A-Glance (TM) overview of the trends.

Interesting finds include

• Web 1.0 has declined by 31% (duh, what is this, the nineties?)
• Web 2.0, 3.0 and 4.0 have enjoyed 200-350% growth (hello, what’s next? The water is wet?)
• An unexpected dip for Web 5.0 (might well be, it’s 2007 for Pete’s sake)
• Immense growth for Web 8.0 and Web 13.0 (so long for triskaidekaphobia)
• Solid growth for Web 20.0 (should be around when Apple finally ships Leopard).

(*) Google