Every weekday, except for Fridays, somewhere around 13:37 the doorbell rings at the Macoscope offices. It announces the arrival of a very special person. Someone with the uncanny ability to unite the entire Macoscope staff, across floors and teams, for around half an hour. His name is Tadeusz and he’s our Chief Executive Lunch Delivery Guy.
As far back as I can remember, we’ve always had this tradition of eating meals together at Macoscope. We like each other’s company, we love to talk, laugh, even argue. And sitting around the table, with delicious food within arm’s reach, is one of the best ways to do so. The food, however, has to come from somewhere and some time ago, after experimenting with a couple of different companies, we found Tadeusz and his wife Hanna. They cook homemade meals which we order the week before and deliver them, freshly made, at lunch time every weekday, except Fridays.
As they aren’t a restaurant, there’s no website or app we could use to make orders every day. Someone has to contact the lovely couple directly with a list of dishes and amounts of each to be prepared for each day of the following week. That someone has to take time out of their schedule to assemble that list by taking orders from everyone at the company. It’s not an easy task and we decided that it could be done in a more effective and less time-consuming manner.
– Ejector seat, you’re joking. – I never joke about my work, 007.
In that spirit, a couple of months ago we formed a team charged with solving this particular problem. With bright minds and a unique set of skills harnessed to the task, we planned, found amazing solutions to all of our problems, began to implement them and… failed. We weren’t beat by the newly introduced Swift, or by coding the backend in this new technology which wasn’t yet part and parcel of our everyday work back then. We were defeated by our own ambition. We tried to solve each and every problem we faced at once, from preparing the menu to placing orders. Add to that the fact that we wanted to do it with the same precision and finesse that characterize all our professional efforts here at Macoscope and the very tight timeframe we were working with, and you will have a good recipe for disaster.
This summer we reactivated the internship program, an initiative of ours that allows talented students to learn how the mobile app development market looks from the inside. We identified two candidates, Bartosz and Krzysztof, and after they passed our stringent testing procedures we invited them to work with us during their summer break. We wanted to show them the actual work, a real project, get them to solve real problems, not just abstract technical challenges. Since working for a client was out of the question, an alternative had to be found.
And there it was, waiting on the shelf, covered with just the right amount of dust. A problem touching real people, people you can relate to, a real world challenge: the Obiad app (depending on your dictionary of choice, “obiad” translates either into “lunch” or “dinner” in Polish).
– If at first you don’t succeed Mr. Kidd…? – Try, try again, Mr. Wint.
But some lessons had to be drawn from our prior experiences. First of all, focus on solving one problem and do it well. Plan features to allow scaling. Have an optimistic version of the app but don’t shy away from settling for a working version as some things may go awry. Ship a working MVP quickly, instead of working endlessly towards releasing a perfect solution.
So, where can we simplify? Deciding who the user of our app is would be a great place to start. There are two main problems to solve here. On one end there’s a person (currently it’s our Office Manager, Klaudia) who has to prepare the menu for the entire coming week, share it with the rest of the staff, collect the orders (and often remind us to place them in the first place), and then send them down the line to Tadeusz and Hanna at the end of the week. On the other side, there are people who want to make the orders and, even more importantly, to be reminded what they ordered when the meals are delivered. We should start with the second group. Every weekday, they’re facing the same struggle: answering the “So, what did I order for today again?” question, while standing in the kitchen, away from their computers and order spreadsheets.
Next up: technology. Our first, failed attempt had a whole custom backend written in node.js. With a web application and a REST API to interact with on both the Web and mobile side. Since we’re solving the “end user” problem, we don’t need a web app, but we still need to store the data somewhere. For now we’ve been using Google Spreadsheets for that particular purpose and it has proven to be good enough, the current arrangement even held up as the team expanded and the menu changed. After some initial research, we decided to use them as our “backend.” The decision had an added benefit: we had a fallback and people wouldn’t have to change the way they order if they didn’t want to. Evolution instead of revolution.
– (…) you’re sure this plan is foolproof? – Yes, because I have anticipated every possible variation of countermove.
Naturally, this approach didn’t suddenly make it an easy task to implement. What we still had ahead of us: learning to log into Google using OAuth and use their-not-so easy API; parsing a spreadsheet, thinking ahead to not hardcode too much; additionally, the data will be subject to manual change by interested parties, and people can make errors. Without some defensive programming all this could lead to errors or even crashes in the app.
It wasn’t just a coding challenge. We tried to treat this as we would a real project. We worked in teams, held code reviews, preparing and maintaining a backlog and sprints in JIRA was a must. We used Scrum with sprints, planning, daily meetings, retrospectives, and reviews with a client, just like we do in any other project. That was a lot to learn for two young interns, but it also some meant taking on new roles for me, personally. Being a Product Owner, Scrum Master, and a client all rolled into one isn’t easy, but it also allowed me to showcase the skills I already have and polish the ones that still need work. Planning work not just for yourself, but for an entire team that relies on your efforts is an interesting change. It demonstrates just how much work has to be done to transform a simple idea into a working part of an application. Creating user stories, grooming the backlog, changing priorities depending on what we can actually deliver within the internship timeframe, all of this just goes to show how much work, besides just coding and design, goes into creating any product.
– Were you expecting an exploding pen? We don’t really go in for that sort of thing anymore.
We released the first version of the app on October 16th. The initial release solved our primary problem. People could check which dish is theirs as they were already en route to the kitchen area, just by checking their phones. Due to sprints and estimations of other features, we were able to squeeze in some icing on the cake in the form of local notifications. One would pop up around the time when the food usually arrives and display the user’s order for the given day, assuming they had one. The other would appear in the morning on days when the user didn’t have any standing food orders, telling them that they will go hungry that day if they didn’t prepare their own lunch or order food from somewhere else.
Next week we focused on another functionality, one which would allow users to forget about Google Spreadsheets altogether: ordering. Because the groundwork for spreadsheets was already in place and we managed to simplify some interactions, completing this task only took us about a week of work. We were even able to squeeze in another notification, for users who forgot to make the order. On the day we wanted to push another test build and send out an email announcing the news, the unexpected happened. Klaudia, the person responsible for preparing the spreadsheets, was leaving for vacation and prepared the spreadsheets for two weeks ahead. Even worse, the entire staff was heading out of the office to work on our core values in someplace quiet in about two weeks, so one of those weeks wouldn’t start on Monday.
But that’s the beauty of planning features and making an MVP. Even when something like this happens, it doesn’t derail the project. We had a working version that people could use. If anything, it was just a minor setback and an opportunity to improve the logic early in the process. One week later, with some adjustments in both app logic and spreadsheets to include more information, like the order deadline for a particular week, and UI changes allowing to switch between weeks, we had an improved, working version ready for release. All this right before the internship program was coming to an end.
– I don’t stop when I’m tired. I stop when I’m done.
Since then we have made a few minor changes made to the app, a couple fixes and some improvements. Apple’s TestFlight 60-day beta periods really do encourage finding time in your schedule to make those. But overall, I really liked the whole experience. I like to build, like to solve problems that are not always technical in nature. I like banding up with a couple of people and hacking out solutions that will get the most out of our prototypes, like to test whether something works, and like to learn. I like that we make mistakes, like that we’re encouraged to not shy away from making them. They always end up teaching us the most valuable lessons, especially when we manage to fix them. And above all, I like this internal approach to issues like these that we have here at Macoscope. When you face a problem, you treat it as a challenge, you don’t just leave it be, you immediately start thinking how to solve it. That’s exactly how we approached the problem of ordering lunch for the Macoscope staff. And what’s next, you ask? Well, we’re thinking of solving the problem of how to open the front gate without moving away from our computer screens…
