Judging the winPHP contest, or 10 tips to make the cut

Early April, Cal Evans approached me with the request to judge the winPHP contest, from a community point of view. After some questions on what the role of a judge implied, I agreed with the contest. During the time the contest ran, I followed the blog posts and tweets about the winPHP contest, and was getting excited to review all those great applications. I figured the judges would be busy as hell in the time between the end of the contest and the announcement of the winners. Seeing all those great contributions, I was actually starting to fear my days of DPC would be filled with application reviewing. It did not exactly turn out that way…

About halfway the contest, a fellow judge told me to lower my expectations. I should not expect hundreds of submissions, but only a couple dozen, of which far from every entry would make the cut. When the ‘cut’ meeting started, it quickly became clear my expectations were far too high. Sure, there were really good submissions, but definitely not as many as I expected. After reviewing the ‘finished’ ones, only a handful made the cut, the cut to be considered a winner. Not that other submissions did not follow the rules, or were not finished, they just did not have what it took to be amongst the possible winners.

After a weekend of carefully reviewing all applications, and how they followed the rules, I made my list of order, and so did the other judges. Surprisingly, the lists were not all that different. Only how heavy each judge weighed a certain criteria made the lists differ. After a meeting with all the judges, we decided the final list. While this list is currently known, I want to elaborate a bit on the pro’s and con’s I noticed while reviewing the applications.

First of all: if the assignment is to build an application in PHP on Windows, don’t have all business logic in a third party application, and only write a nice GUI on top of that. While your application is really cool, and very functional, it does not meet the initial requirements. I am not talking about, for example, an SQL server. That is not business logic, that is data. I am talking about an application that actually provides the business logic. Especially if it is a paid application, and you cannot provide free copies to all visitors of your blog, do not even bother participating.

Secondly: comment your code. Let me repeat that for the hearing impaired: c-o-m-m-e-n-t your code. Even if it is only phpDoc with a short description, your code has to be commented. You are providing it to the community, using it as a proof of concept that the Windows platform can run cool PHP applications too. How can users be bothered to try out your application, if you did not even bother to comment it? How do you get away with that in your day job? I do not care which commenting style you use, comment every line or just have phpDoc blocks, as long as it is properly commented.

Thirdly: collaborate. Us judges had the pleasure to see how two users solved an identical problem together. They actively worked with each other, to write an SQL adapter using Sqlsrv. This was in my humble opinion one of the best plusses I have seen in the contest. If you can work together on a shared part, for two separate applications, you definitely understood the community part of the contest.

Fourthly: contribute to the community. Not only did the two contest participants work together, they even created something in such a way that it was (re-) useable for the community. They created their component in such a way that it could be contributed to a PHP framework, which is used by hundreds of thousands of developers. If you are taking a leading role in writing a good application for a new platform, do it in such a way that you are helping lots of others. You are not alone in the world; others will be following your steps. Save them time, and win the favor of the judges. One of the participants actually made the cut because of this.

Fifthly: do not ignore the existing wisdom. While it is developers nature to want to create everything from scratch, so it will be as good as you imagine it’s going to be, don’t pretend you are the very first one ever to write a web application. Thousands and thousands have gone before you, and ran into issues. They carefully documented the issues, and provided work-a-rounds. Use that knowledge! I do not mind if you want to re-invent the wheel. Hell, I am a developer; I know the feeling all that well. However, if you are going to re-invent the wheel, do it properly. Research what others have learned, and learn from their mistakes. Going to do SQL queries with variables in them? Learn how to safely escape the variables. Building a cool MVC structure? Learn what MVC means, and how it works, and do separate your layout from your logic. You don’t have the time to learn all that, or you don’t want to? Then do not reinvent the wheel, but re-use an existing one. There are tons of well-documented frameworks available, which travelled your path before, and flattened the pitfalls and removed the ambushes. Using a framework for your submission does not mean you are lazy, it means you did not waste time on re-inventing the wheel, but actually used that time for your submission.

Sixthly: write manuals and how-tos. You are writing an application that is going to be used by people other than yourself. At least, that is your intention. Make it feasible for others to actually use your application by providing them with proper documentation. Others cannot read your mind (yet), so write it down. The bare minimum is documentation on what to do to get the application up and running, and a solution for some common pitfalls. It is recommended to add to this documentation on how to use the application, the frontend and the backend. At least one of the participants took this even further, and provided complete videos on how to use this application. Now that is what makes an application attractive for public use.

Seventhly: do not dishonor yourself when giving up. If you cannot make it, be it because lack of knowledge or experience, or simply because of time constraints caused by real life issues, just make known you are no longer participating and leave it at that. Writing a blog post on how much the target platform ‘sucks’ is not going to help your submission. Prove you mastered the issues, teach how you did so, and have a good chance at winning, or just leave it at that. There is really no need to announce publically runs so much better (or just runs) on platform Y if the contest is about X. You’re only publically dishonoring yourself, because everyone else apparently had no issue in mastering the issues, and delivered great applications.

Eighthly: be original. It is easy to provide a solution to a problem already swamped with thousands of existing solutions. Be creative! Find a problem that is unique to the restrictions set by the contest. Deliver a fancy solution for a problem no one has thought of yet. Of course, this is easier said than done. But at least try your hardest to come up with something unique, original and creative. There are already thousands of forums, blogging systems, etc out there. Try your hardest to find something else. Of course, if you really cannot think of anything which has not been done before a thousands of times, it is better to make number 1001, than to not participate at all.

Ninthly: make it work. If your application does not work when the contest ends, your chances of making the cut drop significantly. Of course, it can happen to everyone that you run out of time. We do that daily with our deadlines, right? At least document what is not done or what known issues your applications has. That shows you actually planned your application, and just failed to meet the tough deadline. Do not get carried away on one tiny, but really shiny, valve if the rest of the sewer system is inexistent. Plan it the other away around, so the whole sewer system is in place, except for that one valve. Judges can look past those time-issues, if you documented them properly (as a known issue), and the greater picture is existent.

And finally: participate. I refuse to believe there are only a couple of dozen PHP developers in Europe. I know from the PHP community that there are hundreds more. They all could have a chance to get a free ticket to Las Vegas, or win a shiny XBoX 360. Browsing through my list of contacts, or my public timeline on twitter, I can point out dozens who could make the cut if they wanted to. All they had to do was participate. I am sure nobody did not participate because they did not want to ruin the DPC experience for me, so I see no reason why no one bothered to join in. Of course, one had a wedding, and another just had a kid, and so on, and so on, but if you’re coding at home anyway, why not adjust your schedule a bit, and make something good for the community *and* yourself? I am sure you never regret that decision when you are on the plane to Las Vegas. And if you do not win? At least you learned an awful lot, and contributed a helluvalot to the community. Neither hurts you. Really.

I did not intend to flame any contributor in this post, and left out project names and contributor names on purpose. This article is a guideline to make your submission better, not to make fun of previous submissions. Are you a participant and find this article offensive to your project or to yourself as a person? Please let me know in the (moderated) comments, and I will try my best to adjust this article to remove the offense. Any questions or comments? Feel free to post those in the comments as well. All non-spam, non-change-request comments will be posted.

~RW