Category: Agile

Hackathon: Strategies for building software fast

Last week, I took some time off to join an internal hackathon at work. Nothing comes close to the thrill of going from zero to one in a short time—starting with an idea, executing it, getting stuck, pivoting, and then finally shipping it!

Over the years, participating in and organizing hackathons, I have learned the approach of building software quickly is very different than building good software. I wanted to distill my thoughts primarily for myself and for any teammate in a future hackathon. If it helps anyone else, that would be a bonus!

Start with the End in Mind

Most hackathons end with the teams doing a demo of their implementation. This demo is either done in front of a live audience or submitted as a pre-recorded video. It is the sole medium of communicating the potential of the idea and the product to the hackathon judges. The guiding principle for every decision throughout the hackathon should be this:

What will make the demo an effective communicator of the product's value?

The Team

If you are thrown into a team of unknowns, that’s probably a difficult scenario. Building software is a team sport, and knowing who plays well in which position is the ultimate advantage. Go with your own team if you can.

Dividing work is possibly the most difficult part of the hackathon, and bigger teams make it harder. For a two-day hackathon, a team size of three seems to be ideal; four is the maximum. Beyond that, the speed of communication and integration issues become a major hindrance. The trick to combat this is to use techniques like pair programming or mob programming. It reduces decisions made in isolation. By round-robin the active tasking among the pair working together, you can keep engagement high and reduce the cognitive burden.

Keeping it Simple

Think from the perspective of a judge. If they are reviewing 20 to 30 submissions and can spare about 5 minutes or less looking at your submission, what would make a demo stand out? If your hackathon has more than one theme and you are picking a crowded one, realize that your idea and execution will face more competition.

Aligning with the theme of your hackathon is obviously important, but do not feel limited—creatively add, subtract, bundle, or unbundle ideas. If you have too many ideas or features to choose from, ask how the user (judge) will feel or be impacted if they can no longer use your product or feature (Sean Ellis score). Write the ideas on stickies, put them in a Venn diagram of feasible and valuable. Pick the one in the intersection that minimizes time for feasibility and maximizes the impact on the user.

Code Freeze

Even with familiar teammates, your guesstimates for implementation time would be way off. Add some cushion time to fight Parkinson’s law.  Our general tendency is to keep hacking until dangerously close to the demo deadline, just to pack in one more feature or polish one more UI item. Only to you realize something that was working before is now broken. And it is highly likely that this feature is the most important aspect of the demo. To avoid such scenarios, the first thing to do as a team is to enforce an artificial deadline for freezing code changes. Beyond that, all you will be doing is testing and rehearsing for the demo. This gives you a concrete idea of how much time you have in your hand to implement and integrate.

The Tech Stack

Often hackathons are marketing events organized by a company to showcase their product’s new feature. Even if that’s not the type of hackathon you are at, it would be rare to have zero unknowns in the technology stack that will emerge as blockers. A bug in the tool, your unfamiliarity with the technology, or something completely unexpected is going to happen. To mitigate that risk, you need to reduce the known unknowns. Pick your tools based on what you know, what the app needs, and what you’ll have to learn along the way—in that order.

The Hack

Finally, the most fun part—writing code. Even before the advent of AI for generating code, there were libraries and frameworks that you could leverage to do a lot of heavy lifting. Today, AI is definitely an accelerator for understanding and writing individual modules. However, what remains unchanged is putting the effort of different pieces together. Integration is the most critical and vulnerable part of hacking together multiple components within a short time frame.

As I said in the beginning, a hackathon is the time for building software fast, rather than building robust software. So it is okay to hardcode values and stub out function calls. But you have to bear the cognitive load all along the way on how those shortcuts finally impact the demo. The shortcuts might seem easy to remember in the first few hours, but as the tech debt grows, keeping track of them becomes the real challenge.

Regular Check-ins

Internal communication is the best defense against this brittleness. Your teammates need to know if one of the fields is hardcoded, passing different values in the API call will not change the value in the results.  This is why you need to have regular short check-ins with the team. Set a deadline for the next check-in at the end of one. Have a shared visual board of who is working on what, with swim lanes of To-Do, Doing, Blocked, and Done. Having a list of tech debts might not be a bad idea. As a team, reevaluate and reprioritize your task list.

Knowing When to Pivot

You’ll know. The sooner, the better. Ego is the Enemy. If something is not working, that is not a character judgment. Getting stuck and refusing to move on, however, could provoke one. Feel free to ask for help; trying to explain the problem sometimes reveals the solution. Finding another hack when things are not working is what this is all about.

Get Some Rest

Sneak in some rest from time to time. It is important to give your body and mind a break. Stretch out, stay hydrated, avoid too much sugar or energy drinks. Walk around to say hello to the other teams.

Demo

Finally, show your work – bring out the salesman. Show your work. Communicate the value. And then breathe a sigh of relief that its done!

Despite all the steps above, things will go wrong. Brittle software has a bad habit of hiding bugs until the prime time. So your demo might fail majestically, you might forget the lines that you rehearsed, or your delivery might not be the best. You’ll have a cringy hangover of your failed demo, but trust me, that is okay. It is not the end of the world, it is not your last hackathon. Every hackathon is an opportunity to learn much more than just technology. It is project planning, team building, product management—but above all, having fun! That’s the only strategy that works!

P.S.
1. Thanks to Sayan for his input!
2. Going to post it on hackernews, to learn what hackathon veterans have to share from their experiences in the discussions.

A (Post-Pandemic) World Without Email

Stress induced by unread messages is an undeniable part of modern inbox zero work culture. In a post covid hybrid/remote first world, the trinity of email, Slack and Zoom has become the default knee-jerk reaction for workplace interactions. The lack of physical presence has exacerbated the expected response time of asynchronous messages. While messaging apps are adding LLMs for auto generating responses in seconds, I am here to sing the praises of a book that wants to remove email altogether.

A World Without Email: Reimagining Work in an Age of Communication Overload, was released right in the middle of the pandemic when remote work was at its peak worldwide. The key message of the book could not have been more timely:

Unscheduled asynchronous messaging as the default backbone collaborative knowledge work is detrimental to the quality of output.

What follows are some of my realizations in the process of incorporating the principles from the book. I became convinced that for building high performing teams for collaborative knowledge work, we need a culture shift. And that can happen only when organizational leadership commits to workflow design with empathy, instead of incessantly chasing work execution.

Knowledge work – The Workflow and Work Execution

The book’s central thesis revolves around the idea that there are two facets of knowledge work: workflow and work execution. The growth of white-collar jobs during the economic boom of the last century has led to a substantial portion of the workforce engaging in knowledge work. However, due to its intangible nature and rapid evolution, there has been a significant lag in the development of efficient workflow design. The lag was further impacted by the digital revolution, specifically the emergence of email and chat as ubiquitous communication tools. These technologies facilitated lightning-fast message delivery across the globe, resulting in widespread addiction under the guise of collaboration.

This short-sighted view on immediate results neglected the long-term consequences of email driven work culture. Computers and networks kept getting faster, but the human at the either end of a message did not. They jumped from one unfinished task to another, with an illusion of multitasking like the computer. Busyness became synonymous with productivity.

Cal’s manuscript was probably done before the pandemic, so there is no reference to work during lockdown, but we all know what happened. Our lack of preparation for pandemic led to a global spread of the deadly virus. Much like that, when the lack of efficient workflows met with an abrupt switch to remote work, it left the knowledge workers inundated by non-stop Zoom, Slack and emails.

Refocus on Workflow

Any task in a collaborative knowledge work environment goes through a set of state changes – inception, discovery, refinement, work in progress, execution, waiting for feedback, completion. Without a predetermined protocol, every task needs to establish the next steps to completion through unscheduled asynchronous messaging in the form of an email or an instant message. The book describes this chaotic state of collaborative work as the hyperactive hive mind which eats away the attention capital of the organization. The open loops of unfinished work linger long after designated work hours as people struggle to fall asleep while scrolling through unread messages on their phones.

Jira, Asana, Pivotal Tracker, Trello – there is no shortage of tools in this realm of ticket based workflow design. If you are already using one and not getting the benefit, ask the following questions:

  • Is everyone in the collaboration ecosystem is onboard to using it?
  • Are the list of tasks gets reviewed at regular intervals to evaluate progress against deadlines?
  • When new work or uncertainty surfaces, is there a knee-jerk reaction of shooting an email/instant message or opening a ticket?

Transitioning from email to workflow tools in five steps

Take a step back and try to understand the complex patterns in your team’s work.

  • Start with a prioritized queue of tasks needed to take an idea to completion
  • Define the different states a task can be in. Start simple ToDo, Doing, Blocked, Done. Don’t over-engineer, stay between three and five.
  • Have a predefined protocol that determines who does what at each state transition
  • Have a shared view of who is working on what and which state the tasks are on
  • All asynchronous communication for discovery, decisions clarification, execution, feedback etc. happen in the context of the task

Role of leadership

The role of leadership buyin is the linchpin here. Once they see that chasing the stream of consciousness from the hyperactive hive mind is not the best collaboration strategy, it becomes straightforward to establish a culture that translates work into meaningful actions within the framework of tools and processes.

Work Execution Modes – Specialist and Support

To gain something valuable like autonomy, you have to offer unambiguous value. You have to be accountable for what you produce, if you want the freedom to improve how you do so.

– Cal Newport

In typical knowledge work, contributors have the opportunity to deliver value in two distinct modes. The first is the specialist mode, in which they can immerse themselves in deep, solitary work. The second is the support mode, which involves engaging in collaborative problem-solving. When the support mode is neither scheduled nor governed by structured protocols, it can easily transform into a source of incessant distractions, thereby impeding the performance in the specialist mode. Meetings, whether in person or remote, are the bedrock of support mode and possibly is the second most hated artifact of collaborative knowledge work after emails.

In today’s hybrid work environment, it’s crucial that we foster a cultural shift towards empathy, avoiding unnecessary calendar clutter for our colleagues. It is inspiring to see some organizational leaders championing ‘meeting-free quiet days’. Yet there remains ample room for improvement. Hopefully in the future, calendars will not only check for common availability, but also factor in the priorities of their deliverables and the cognitive burden of the employees to avoid burn out. Till then, here are some pragmatic approaches to calendar management.

Collaboration hours

Proactively providing designated time during the week as collaboration hours cuts down adhoc exchange of messages for agreeing to a meeting time. Anybody seeking your time for any collaborative work like knowledge sharing, discovery, troubleshooting etc, can use these slots. Outlook, Calendly, Gmail all provide options for booking time and even encourage putting them in your mail signature/chat client status.

Standups

In software teams, a common practice is to conduct a daily standup meeting. During this meeting, team members take turns summarizing their accomplishments from the previous day, setting objectives for the current day, and addressing any obstacles they may face. When conducted with the right mindset, this can be the most effective meeting a team can have.

These meetings are called ‘standups’ deliberately to keep them short. If a standup involves more than six-seven people or takes longer than ten-fifteen minutes, it has likely become unproductive. Any other topic otherwise is discussed in a ‘parking lot,’ where only needed team members break out to address specific obstacles, streamlining the main meeting. 

Ad Hoc meetings

While the above methods significantly reduce the necessity for impromptu meetings, they cannot entirely eliminate them. Structure the agenda as a list of questions on a shared document, each with possible solutions, and convert meetings to decision-making process. The outcome of the meeting are action items for designated team members with deadlines which should get reflected/tracked on the workflow tool described above.

Other experiments

While that utopian day of the world without email is still far out. Personally, beyond the rules for auto-deleting and auto-archiving, those email that contain information but need no actions I manually push then to my Projects/Areas/Resources/Archives folders in my second brain using OneNote and Outlook integration. I never touch them again in Outlook, but progressively summarize them in batches.


Emails that need actions I forward them to Jira, using email to jira integration. Those that absolutely need replies, I try to shut down those threads completely with super short replies containing hyperlinks to jira tickets, wiki pages, shared documents with checklists and instructions. It is a game – if email replies exceed five sentences, I reevaluate what more can be done to liberate the task out of email entrapment. To reduce slack messages, I’ve been experimenting with Canvas where we keep a list of open items to be reviewed during scheduled meetings rather than defaulting to adhoc pings.

Conclusion

Email’s impact on the workplace was not additive; it radically transformed the very fabric of knowledge work and our professional lives. In the wake of the pandemic hangover, our society finds itself grappling with the cognitive load of increased digital communication, all while navigating the pressure of return to office. Let’s be more intentional than adhoc to build a future where the distraction of unread messages, or the anxiety of their accumulation, no longer dictates our capacity to deliver our highest quality work.