Ever had a 10 AM Sunday coffee at work?
I, at least, hadn't. Until a few days ago, when I entered the office for my third day of our outrageous Friday-to-Monday hackathon. That's 4 days. To build an app.
Right, I needed that coffee. It had the usual comforting smell, but with extra layers of why-am-I-here faces, what-day-is-it puzzles, and where's-my-sleep eyes.
Why would we do such a hackathon though?
R.A.D. (Rapid Application Development)
We all wish a lot of stuff in our lives happened faster. We strive for efficiency and optimization. However, some things you just can't put on fast-forward. You can't microwave the quality of an app, for example.
But you can better your processes so that you reach that optimal point where quality meets fast(er) execution. At the end of the article you'll see why this can take you a long way.
Rapid Application Development is not a new way of building products. It's similar to the agile methodology, focusing on fast releases and iterations, and relying on feedback (both from users and from software) as opposed to tight planning and deadlines for big releases.
The challenge is to make these frequent releases not only faster but also better. In business lingo, this is a lean approach. And we were eager to try it out.
That's why our challenge for the hackathon sounds like this:
Choose one real project estimated at over 3 months development and try to finish it in 4 days... You can to use any tool - free or paid - to get the job done. You should also align your team, tools and processes extremely well since the time is clearly not enough to get you there in the traditional way.
The idea was to find proficient tools and processes that we don't have the time to test on day-to-day projects. In the greater scheme of things, we should be able to transfer the good practices we found towards our day-to-day projects.
Can we do this?
We split into 4 teams, each with a designated team lead.
Each took a project with minimum documentation and designed a strategy to build a deliverable out of it in 4 days.
Results: delivered an almost-ready MVP in 4 days;
Features developed: authentication, search, registration, validation, business account, user account, in-app video upload, social account/email login, SMS validation, notifications, logout.
Challenges: Firebase proved to be slower for advanced developments;
Learnings: Alex and his team started the experiment in a very organized formula, but they could not sustain it until the end. All in all, they found:
- they started with building the components (this made the frontend side move faster), many of them worked with new tools and thus were able to let go of those that were not working.
- Strapi would have been a better fit for the project (instead of Firebase);
- experiment was useful, but they still needed at least two more days in order to ship a more polished MVP.
Results: A booking app with basic features, for both iOS and Android;
Features developed: email authentication, widgets for displaying content on home screen, product page with details, booking flow: browse availability -> select item -> add items to cart -> select hours and date -> dashboard with selection details, booking status updated in real time.
Challenges: team cohesion and motivation were not constant during the event.
- If you really want to do fast-paced development, each person should know to do their part very well.
- Calin and the team learned how to use primitives, which are the smallest and most frequently used UI components. And that the new React Navigation is cool.
- From team 2's perspective, a better way of doing rapid development is by building each feature in its whole functionality and then refine the details.
Results: Delivered an MVP in 3.5 days;
Features developed: login, register, password validation, SMS verification, in-app markdown editor, in-app search, dashboard, static map generation, email templates via Sendgrid.
Challenges: Keeping schedules in check - even though for the most part of the hackathon we were together, there were moments when we were parting ways without giving a proper status update. That led to some double work here and there.
- Material UI is cool - it has components for everything.
- Strapi is ideal for fast development - with its default-generated endpoints and ease of adding custom ones.
- Darius' team didn't apply best practices only, but it's a hackathon so they did the job using a combo of R.A.D. and experimentation.
Results: developed the frontend and backend infrastructure for a web and mobile app using a quality-first approach.
Features developed: Developed and tested all components needed in the web app and assembled them in screens and partially integrated them with Firebase.
Challenges: One developer was sick for most of the hackathon so the development rate on the frontend was reduced to almost half.
- Cosmin's vision was to approach the task by rethinking the entire development process and break it down to smaller, more manageable parts through a bottom-up approach.
- They worked on a single master branch and each on separate components that they could test individually and actively by another team member (PM)
- With this approach they could compose these parts into full screens and have complete functional features in as little as a few minutes. In fact, Cosmin was able to build 10 functional screens in 30 minutes.
- For them, Rapid Application Development proved to be a good strategy, bringing thorough analysis of each task and a clear and steady-paced work style.
Think about This
What do you do if you're tight on time with your project?
Do you work harder and more? Or do you try a complete mental shift and look for new ways of doing your job?
We wanted to answer to the latter.
As you read, we didn’t actually build an app in four days. The truth is, we didn’t even expect to.
But we gave it a try anyway.
Because we wanted to disrupt our own way of working, our comfortable practices that, despite being efficient, can sometimes make us forget there always is a better way of doing things.
👀Major tease: one of the projects at the hackathon will actually be built out there, in the real world. Subscribe below to learn what will happen with it and see if the hackathon helped us get closer to new quality standards.