Andrew Fitzpatrick, from's Hackathon team talks about the process, development and results of a product development hack.

Software Engineering Team Tech Topics: No.3 Hackathon

Andrew Fitzpatrick -  15 Sep, 2015

“None of us are as smart as all of us” is one of the values that our product owner likes to test using intermittent Hackathons.

Hackathons are a trending topic within the IT sector and are used to bring together teams of delivery specialists to work towards a common goal in a fixed period of time. At, we like to run our hackathons over the course of 1 day with the outcome being a working demonstration of functionality that may, or may not, end up in the core code base.

The subject of our most recent Hackathon was ‘notifications’ with our requirement being: “we want services to notify users when something relevant to them happens, so that they can act on it”. Notifications within our new booking tool will manifest themselves in two ways, firstly the user will receive a message in the browser based UI; secondly an email will be sent to the user. Both will have the same content. We don’t want our users to be bombarded with notifications so the purpose of them will be to inform when something out of the ordinary happened, like their hotel booking failing to confirm. The user interface will show all unread notifications by default and the user has to explicitly mark a notification as read as they are important. The UI will also present the ability to read historic notifications so that users have access to the full story of their bookings.

Prior to the hackathon day we held a domain session as is the practice with domain driven development. During this session we pinned down all the domain concepts and the ubiquitous language to be used. This provided a foundation for the day to ensure the output would adhere to our high quality standards and fit into our current architecture.

The team that embarked on implementation for this hackathon consisted of the product owner, two engineers from the Travel team, three engineers from the Supplier Federation Service team, two engineers and a designer from the UI team, and an engineer from the Platform team. This mix ensured that all four technical areas within the software engineering team were represented.

At the start of the day the team held a brief whiteboard session where we reviewed the planned deliverables and design to ensure we were all clear on our target. A formalised version of the output of this session is as follows:


  1. An events occur that require notification in Travel.
  2. The notification is posted to the Notifications SNS topic.
  3. A Lambda function is subscribed to the SNS topic, the function reads the new message.
  4. The Lambda function saves the content of the notification to DynamoDB
  5. The Lambda function also uses another bounded context to send an email to the user.
  6. An API client polls a REST endpoint for unread notifications. The REST endpoint is configured using API gateway and communicates with a Lambda function.
  7. Lambda function reads from DynamoDB and returns the required result to the client.

With the design decided, we set to work…

How the hackathon played out:

11:30 - Implementation started properly, branch of master created, most team members set up in the board room although the UI team needed the larger monitors at desk.

13:30 - Product owner provided the team with pizza to keep us all going. By this time we had the SNS topic in existence and many of the elements close to being ready for a first test

15:30 - Travel integrated with SNS and posting messages to the topic. Lambda persist and email function implemented in JavaScript saving the notification to DynamoDB. Other Lambda function set up and able to return notification messages.

17:30 - Travel tweaks applied to mark-up part of the notification and add createdDate. Lambda API Gateway added for accessing the notifications resource script.

At this point we were close to a good end to end so our product owner agreed that some development could continue to a second day. The team thinned slightly as some areas were dev complete.

12:00 - First cut end to end integrated.

13:30 - Second version of end to end integration including some minor bug fixes discovered in the first test.

14:30 - Third version of e2e integration including sorting of notifications. Notification panels were also integrated with the main UI, albeit using dummy data.

By the end of this day the code was dev complete and ready for a demonstration the next day. Although the elapsed time ran into a second day, actual effort for each participant of the hackathon was roughly a day each.


The final task left was a demonstration of what the hackathon team created. With the library area booked and team members dialling in from all over the world we showed:

  • A booking failure in Travel triggers a notification which is placed on a SNS topic.
  • A Lambda function picks up the message and persists it in DynamoDB.
  • The function then fires an email to the user.
  • A Lambda function and API Gateway can be used to provide a REST endpoint to: 
    • access read messages.
    • access unread messages.
    • mark a message as read.
  • A user interface for interaction with the above endpoints.

In the top-right corner of all new client apps is a notification bell icon. If there are unread notifications, the number of is also displayed.

Clicking the bell shows the unread notifications - to mark a notification read the ‘X’ button is clicked. Arrows show that the notifications are paginated.


Clicking ‘Previously read’ shows the notifications where they ‘X’ has been clicked. The ‘<’ can be clicked to return to the unread messages.


Clicking ‘Settings’ shows the available settings for notifications, this is a placeholder screen as the functionality is non-MVP. The ‘<’ can be clicked to return to the unread messages.




This hackathon was a good experience and has given us some useful learning points specifically around environment setup. We learnt that we need to start integrating functionality early to give ourselves the best chance of a successful outcome, it also gives the best reference implementation for all involved. This is one of the points that will be taken forward into the next hackathon. One thing the hackathon has proven is that by bringing together a diverse team for one day can deliver a solution which has a touchpoint within each team and something that may take a couple of weeks when left to the standard backlog delivery model can be achieved in a couple of days. Adopting these innovative ways of working means that the development team within Click Travel is at the cutting edge of technology trends, something which we are all proud of and which is good considering technology isn’t our core business. We look forward to the next hackathon, watch this space for details...

Check out our previous Software Engineering Team Tech Topics here.

Subscribe to this blog

Use of this website and/or subscribing to this blog constitutes acceptance of the Privacy Policy.