Guide to Competitive Software Demonstrations

Firstly, know that your software – a mobile or desktop app, a website or an API – will probably be overshadowed by projects more hardware-oriented, like a robot or an Internet of Things (IoT) device. The reason is simple: it looks better in a stall. You can clearly see the judges' eyes glittering with excitement when they see a mechanical hand being all robot-y and whatnot, flinging itself here and there while their makers are busy describing the cultural significance of its every move. Compare that to the dull screen of your handheld device showing dull pages filled with dull text and you can justify the complete lack of gleam in the judges' eyes.

Don't get me wrong, I'm not discrediting mechanical projects. Those things require a lot of effort and unlike your typical app or website, cost a lot of money. It's just unfortunate that most (almost all) project contests force mechanical and software projects to compete under the same label. But since there's seemingly no way around it, you have to make do. Improvise. Adapt. Overcome.

One option is to go cross platform. If you made an Android application, try to make one in iOS. Make a website version of it, or a desktop app. If you can't fully develop it in another platform, maybe just make a website for admin activities. Or if you just have a website, you can quite easily make an Android app version of it. The aim is to add layers to your product as easily as you can, without sacrificing your main features. Since demonstrating something on a screen can turn boring, provide multiple screens to focus on. If you've got development time for either adding a new feature or going cross platform, go for the latter. Adding dimensions to your projects can be more effectively achieved by adding devices for demonstrations rather than features. But of course, this technique wouldn't work if your project's features are basic or hollow. In that case, nothing can save you.

Another option is to go all out on stall decorations. The norm was to not care about how stalls look. I went to my first app contest with a lot of hope and one poster, fearing that my stall would look empty. I went there to find that I'm the only contestant with a poster. But as much as I looked like the odd man out, I didn't want that BDT 300 to go to waste, so I kept it hanging. But the tides have turned since then and more participants are decorating their stalls with posters containing illustrated descriptions of their project features and animations or video tutorials playing on their laptop. These invariably have the effect of showing how very dedicated the team and how grand their project is.

Go all out on preparing for your demonstration. This is common advice for any project in general. But it seems more suited for computer science students because of their stereotypical tendency to prefer code over human beings. All your effort behind programming, integrating, and testing will go in vain if you can't make the jury understand what your software does, what's unique about it and why you're so passionate about it. Leave the last hours not for coding that last bit of code to get better finesse for the app, but for practicing your demo.

Be smart about what features to include. If you have a management app with a twist, don't waste your time working on the authentication system. Work on the twist. Show the judge the twist. The judges are in no way interested in figuring out the nuances of how a user can sign up. That's for your university project.

Speaking of being smart, your smartest decision should be the one that involves deciding what your project will be built upon. The general consensus is to go for technological innovations to solve a general problem. But provided it's not possible to emphasise on both, do you make the technology the highlight of your app or the solution to the general problem? The easiest answer would be "make it perfectly balanced, as all things should be." This eliminates any chance of you blaming me for not winning with your "imperfectly balanced" project. But from my experiences, I must say technology trumps solution. Odds are, whatever general problem you're trying to solve has already been addressed by multiple projects which the judges have grown tired of. If they've not been addressed, then it could be too niche for the judges to relate to or take seriously. Buzzwords, on the other hand, like AI, AR or Data Mining are what judges dig. Throw in all the code related to the buzzwords and you got a project with a fighting chance.

I'd like to end with a very personal (and cautionary) piece of advice. If your software is Internet dependent, rigorously check the venue's Wi-Fi system. Please.

Fatiul Huq Sujoy is a tired soul (mostly because of his frail body) who's patiently waiting for Hagrid to appear and tell him, "Ye're a saiyan, lord commander." Suggest him places to travel and food-ventures to take at fb.com/SyedSujoy