The famous Sitecore Hackathon is an annual programming contest, where teams should put together, within 24 hours, a piece of software for Sitecore in one of the available categories. At this fourth edition in 2017, there were four categories: Azure PaaS Module, Sitecore Experience Accelerator, Habitat Module and Data Exchange Framework – this last the one the Go Horse Team picked.
92 teams participated with members from 26 different countries!
This was our first participation, so we were not sure what to expect. Like any other professional development we execute, we made sure to read all requirements and rules and to strictly obey to everything: deadlines, supporting documentations, Youtube video, the software itself, etc. And yes, that was important, as we’ve seen so many teams being declassified by not following just a small portion of these.
The Go Horse Team
Our team was composed by Anderson Fortaleza, João Amancio Neto and Rodrigo Peplau (myself). We joined together because at that time we were colleagues at Nonlinear Creations in Florianópolis, Brazil. Nowadays João is at Virtual Affairs in Netherlands, and I am working at Nish Tech Inc.
The Go Horse Process is a joke in the form of a software development anti-pattern. Despite everybody knows its practices are not to be followed, the funny part is that at some point in our career, everyone had to “follow” it to deliver in time. Some of its axioms are:
- I think therefore it’s not Go Horse - In Go Horse you don’t think, you do the first thing that comes to your mind. There’s not a second option as the first one is faster;
- There are 3 ways of solving a problem: the right way, the wrong way and the Go Horse way which is exactly like the first one but faster. Go Horse is faster than any development process you know
These funny principles are pretty self-explanatory and also gives a sense of our mindset for this 24 hours contest: we got no serious ambitions, we were there just for fun, we had to be “pragmatic” but deliver something functional within the deadline.
Choosing the subject
Maybe one of the most important steps, if not the most important, was to select the subject. This step will define if you’ll have a good chance to win or if you’ll fail miserably. The first thing we made was to take our team out of the computer and go to a place where we could brainstorm.
Next, we got to measure our team and the individual skills of each member. Maybe a member of your team masters Azure technologies while other is good at doing SPEAK interfaces. During brainstorming, we wrote down any ideas (bad, good, mild) that came to our mind based on every subject of the contest. We opted as individuals to not be afraid of suggesting dummy ideas, which encouraged the whole team to not be afraid as well. Remember: from stupid ideas, good ones can come forth.
We ended up with the idea of using the Wikipedia API to generate content inside Sitecore, using Data Exchange Framework. Of course, other suggestions came before, but we decided this would be a simple one and easy to execute. One of the team members had already done some integration with Wikipedia’s API before so he was familiar with that. Other member had already implemented some SPEAK interfaces before. What remained? Learning Data Exchange Framework.
Some important things at this stage:
- Avoid spending more than 1 hour to choose your subject. It is a 24 hours competition, and the software itself is only part of the delivery. Every minute is of much importance;
- Don’t be too ambitious. Again, the short time to implement won’t let you much time to refinements. It’s better to deliver something simple but that works, then having to deliver something unfinished or buggy.
Execution: Work distribution and Teamwork
We choose our theme, made sure every team member was comfortable with that. What now? Let’s start to plan the execution. Who is going to do what? You don’t want to have in the middle of the Hackathon somebody in your team uncomfortable with the plan and willing to change everything. It’s the receipt to fail miserably.
In our case, I was already experienced with SPEAK, so I got responsible for the interfaces, which took most of my time. Anderson and João took the responsibility to learn Data Exchange Framework, understand how it works and come up with technical solutions that I would be binding together with the interface. From time to time, we stopped our work for a quick desk check, in a way that the whole team is aligned: I got to understand how the framework works, they got find solutions to our software needs such as how to programmatically trigger data importation.
Take a rest! It’s important
It was also very important to plan and optimize our team member’s presence. 24 hours is a little time to develop a software, but is time enough for people to get tired, and we don’t want everybody sleeping at the same time. So what we did was to plan our rests in such a way that there’s always someone producing. Honestly SPEAKing I tried to sleep but I couldn’t, my mind couldn’t stop scanning all gaps and possible flaws, so I took the time to lay down, rest my body and keep on planning and projecting.
As previously described at this post, the software itself was only part of the whole deliverable. Along with that, we had to prepare 1) Installation instructions (1-2 pages); 2) Module documentation (2-5 pages); 3) A video explaining the module (2-10 minutes). These tasks seems trivial, but they also demand strict attention as they count as much as the software itself. We split these tasks into our team members, each of us doing one of these.
When everything was pretty done we still had about 1 hour to deliver, so we concentrate our efforts to revise everything. Members started to check each other’s work: does the documentation makes sense? Is there any typo? Is that covering everything? Is the module installing and working in a vanilla solution? Everything should be well aligned and ready for deployment.
Respect the deadlines!
We ended up uploading our work 20 minutes before the deadline. That is also something extremely important to respect, as the judges are not tolerant to delays. Our friends from the “Works on My Machine” team took more than it should to deliver and had their Dropbox access cut in the middle of the upload, which is frustrating after so many hours of hard work.
Since that was our first participation, we were not expecting to win. Surprise, we have been announced the winners, with very flattering feedbacks from the jury.
Main lessons extracted from their feedbacks:
- Choose something with a practical use. It is ok to implement an abstract case study, but if your module have a real life use, it may help judges to understand it, which can potentially call their attention to your team;
- Be respectful to the category you chose. No matter what category you picked, someone have implemented the base software you will work to extend. Respect its principles and best practices, implementing something that creators will be glad to see.
Our module – WikiDX
Resulting module is called WikiDX and is available to download at the Marketplace – check it out!
Now that members of the Go Horse team are not working at the same company, will they be at the next contest? Of course we will! We need to defend our belt and have fun together again! While João is in Netherlands, and thus will have to join us remotely, myself and Anderson are still living at the same city, so we plan to get together for the next effort and repeat the good work.
What would we make different?
We were newbies and didn’t know what to expect. Our preparation was close to zero, we just got our own professional experiences and a lot of curiosity. For the next year we plan to have a better pre-Hackathon preparation: getting familiar to existent categories, getting to know for instance Sitecore on Azure, SXA in deep, etc. But it is also important to keep an eye at the new modules Sitecore launches, as new categories can arise. Data Exchange Framework for instance, was a new category this year, and has been released just a few months before the Hackathon. As a result of this preparation we may end up with a collection of knowledges and code snippets, which could be very helpful to a smoother execution.