We had three hours time and were to work in groups of four. I teamed up with Sebastian Bergmann , a natural choice given the fact that I was travelling with him, and he is one of my business partners. We were joined by Carl Vuorinen, another speaker at the conference. We agreed that Carl would do the JavaScript frontend part, and Sebastian and I the PHP backend part. After a while, we were joined by Jakub Gimiński, who started helping out with implementing the backend. Having Sebastian Bergmann and me on the team, it was pretty clear that we would aim for full test automation, and not even consider using third-party code unless we had to.
And here is the first problem: you are in a hackathon, and have three hours time to complete the task. Now how much time do you spend getting people on board? Right, not enough. And since there were four people with different operating systems and PHP environments, which environment do you agree on using? Sebastian and I were already using PHP 7, but the other two were not. Plus, we were to deploy our solution on a cloud platform without any knowledge about the environment it would support. It took Carl quite a while to set up the cloud server, because he had to familiarize himself with the interface. And only towards the end would we know what version of PHP it would support. Of course, the differences between the minor versions of the PHP 5 release series are rather subtle, but not knowing what our target platform would look like until we were one third through the project does not feel right to me.
Up To Speed
Another couple of minutes were spent on getting Jakub's PHP environment up to "standards", at least up to what Sebastian and I would consider standard. Again, I felt rushed because the hackathon's goal is to get the job done, so anything besides writing code feels like a waste of time.
As I was working on the API, I realized that the specification was lacking: we were asked to implement a method to assign a tracking number to a shipping container. According to specification, this tracking number was to be provided by the client. Of course, this does not make sense. The more complex a tracking number format is, the harder it will be for the client to enter or pick a valid number. Plus, we have to ensure uniqueness, which is hard to do before actually saving it. Ensuring uniqueness quickly becomes impossible when you have to distribute your system. It would be much easier to have the system assign a (valid and unique) tracking number when the client registers a container. This is the solution we implemented, and we documented our decision and the reasoning for it. Our solution is on GitHub , by the way, if you want to have a look.
Going on three hours, Carl had been successful in writing the frontend, however the web server was still not configured properly, also due to the fact that we had opted for a clear separation between API and frontend, but were lacking a hostname for our virtual machine. With just an IP address, setting up two different sub-domains ... well. Of course, the web server can be set up differently, but this is not according to what we were used to, so it took us longer than it had to. We also were not able to run the API over HTTPS, as you should, because we had no certificate. And importing a custom CA into the browser ...
The whole hackathon felt like we were solving all the problems of a decent-size project, but we had to rush everything, because of the deadline approaching rapidly. Of course, there was beer and pizza, and we were all positive that we were not doing this to win, but to have fun and learn. In the meantime, Sebastian was coaching Jakub, who was not very familiar with unit testing, to write tests for the value objects he had created. I had whipped up a small "framework", consisting of a HttpRequest
and a HTTPRequestUrl
class, which are still lacking tests, because I "had no time". I got close, but was not able to finish up my code and to make the application work.
Almost Done
At the end, we had about 500 lines of decent PHP code, not fully tested, but all our tests passed. Carl had written the JavaScript code using AngularJS. It worked. Or at least, it would have "really" worked if we had maybe had another hour, put the web server into place, and integrated everything. As a matter of fact, Carl has forked the repository (we had decided to keep its original state) and finished up the software after the conference.
Going back to the hotel, I realized that during the hackathon, the tight schedule had forced us to do pretty much everything that we all know you should not do. And that we had just experienced a "real" project situation: a tight deadline, not enough communication "because we have no time", rushed technical decisions like just using HTTP "because we have no time", doing things quick and dirty "because we have no time". Does that sound familiar to anybody? Exactly: most teams that I have met (and I have met many of them) experience just this on a day-to-day basis. And it is wrong.
Dear organizers of that hackathon: I thank you very much for making this event possible and all the effort you put into it. It has been great fun, and I have learned so very, very much. It has been a priceless experience. As a consequence, I will never ever take part in a hackathon, because it forces us to do pretty much everything the wrong way. When developing software, the goal is not to write a lot of code as quickly as possible. We need to communicate. We have to agree on how we do things. We have to get everybody on the same page. We have to make conscious decisions. We need time to understand the requirements, and we need a feedback loop to clarify them, especially when we think they are flawed. We can never make compromises when it comes to security. Who cares whether our web server is secure, we just had 15 minutes to set it up, and thanks to cloud computing, who would ever assume that it might take longer to actually think about how the live environment should be configured.
Considered Harmful
Hackathons should be considered harmful. They teach us to work in exactly the way all our experience teaches us we should not work. How about running a dev-a-thon instead? Give everybody access to a sane development environment, and make it look the same for everybody. There is no point in wasting one third of the hackathon's time in straightening out technical issues. I am well aware that working out quirks and issues is an essential part of a developer's life, but a team of different people agreeing on a development and live environment takes far longer than one hour (and in real life, one hour does not translate into one third of the project duration). Prepare the same live environment for everybody. Put deliberate flaws into the specification. Encourage every team to challenge and modify the specification, documenting their decisions and the reasoning behind it.
Please note that this text is neither meant to be an offense against the organizer of the hackathon at Bulgaria PHP nor against the organizer of any hackathon. I will gladly make myself available to coach teams through any dev-a-thon-like event that has a strong focus on the right values.