About the add-in contest results

First of all, congratulations to Roland Weigelt for winning the first prize in Roy's Add-in contest!. I think his entry deserved the first prize without a doubt as the tool is amazing and, when extended with some additional logic/features, could become a big commercial success.

As a judge in the add-in contest, I had to test all the add-ins submitted, and judge them on quality and if they deserved any of the big prizes available. I can tell you it was hard. Not because there were so many good entries, but because it was often very hard to even get the submitted code to run, left alone to find any documentation what to do, how to get started. This really surprised me, I have to say, and I don't think it's a good sign.

There was just one add-in which had proper documentation how to get started, what to do to see it in action, complete with a well working installer (so it does get uninstalled properly as well, lots of add-ins failed in this, which is annoying to say the least). That add-in turned out be the winner: Ghostdoc. What surprised me was that of all the add-ins submitted, only a small part of the add-ins even had an installer which was ready to use. Most of them came with just the sourcecode. I even tried to compile a few, some failed during the compile! So, as a judge I was sitting there.. "What to do with these add-ins?" I asked myself... Some had nice ideas behind them, but if it doesn't work, the idea just stays an idea.

After a while I simply gave up. It would just take too much time to wade through the sourcecode of these add-ins to get things starting, compiling the installer projects and fail doing that (that was the irony: some had installer projects, but not the compiled binary!) and to figure out what to do with it. Till now I really can't understand why all but one (Ghostdoc) failed to include proper documentation to get started within a few seconds, get it working, where to look at, what are the highlights. I mean, if you want to win a contest, you want to make sure the jury can at least run your add-in and try the killer features of it, right?

Documentation, how to get started, simple demo apps, it's all part of the tool / add-in you're delivering. If there is just sourcecode in a directory, that's not enough. Users don't have time to figure out how brilliant you or your code is, nor do they want to. They want to use it, because they have better things to do with their time. If there is severe lack of documentation, info on how to get started, even a proper working ready-to-run installer, the overall quality of the tool / add-in is close to 0, zero, zip, nothing, void, null: it is then nothing more than a bunch of files with data, but how to use that data, how to utilize that data to be more productive, produce better code, have a better life or whatever, that's unknown. And to me that's unnecessary, because it doesn't take that much time to explain simple things like getting started, what to do to see it in action (yes, this sounds silly, but try the add-ins for yourself and you'll find out very soon it's not that easy), and the most simple thing of them all: how to get it installed.

It's sad to see some hard work not ending up in the top 3 of the contest. I'm sure if some add-in writers would have spend 5 minutes on a working installer and a proper readme.txt how to get started, the top 3 might as well have looked completely different, at least from my judgement, although Ghostdoc would still be a winner I think. I must admit that the 2nd and 3rd prize winners weren't my choices for these spots but luckily for them there were more judges in the jury . To the add-in writers competing in this contest I'd like to say: thank you for participating in this contest, but try to learn from what Roland submitted: look at the overall package, the quality of what was submitted was almost near the quality you'd expect from a commercial tool/add-in. Often it requires just a few extra hours of work, but it will increase the quality the tool/add-in you're producing tremendously, and that's what counts, trust me.

6 Comments

  • Basic software 101. Thanks for writing the lesson so well in hopes it may inspire others to follow good practices.

  • Certainly it sounds like the quality of the add-ins submitted could/should have been of a better quality.



    To be fair, however, as with most contest and competitions, there is usually criteria given as to how the judges will be scoring the entries and some basic rules as to the minimum criteria for even accepting an entry. I checked out the contest URL you mentioned in your post, and it really doesn't give an author of an add-in any clue as to how the judges would be evaluating add-ins or the minimum acceptance level of an entry.



    I recommed that future contests be more formal in contest rules and judging criteria. This will not only assure you get the quality of submission you are looking for, but 1) help the judges be more consistent in their recommendations and 2) help the contestants understand the rules of engagement :)



    It sounds like this contest had a few bumps, but given all that was learned, I bet the next one will be better. Plus, given the competition wasn't too fierce, I bet future contests will have a lot more entries :)



    I think these contests are a great idea. Thanks to Roy, the judges, contestants, and sponsors for paving the road to more contests. I'll show more community spirit and enter the next one, making myself vulnerable to the judges and community at large :)

  • This is excellent advice for everyone involved, Frans. A great article and resource for anyone looking to develop an add-in for VS. (I'll be taking this to heart, for certain).

  • Who won the contest??

  • So what will happen to all the submissions?

    How about posting them somewhere after taking the author's permission. This way their work didn't go for nothing and the programming community will learn how to write an add-on.

    Personally I don't know how to code one and looking at someone else's code will give me insight.



  • David, the fact that a softeware development contest rule that says "your software should be installable and have documentation" is needed is a sad statement of the state of development skill in our industry.

Comments have been disabled for this content.