Our development approach to the LINE Official Account app

Hi there. I'm Zhihao Zang, an iOS engineer on the LINE App OA Dev team. We are the team behind the Official Account functionalities in the LINE app, as well as the LINE Official Account app.

I joined LINE Corporation (which is currently known as LY Corporation) as a new grad in 2018, so this is the first chance for me to work in an international, professional software development environment. It's fascinating to see and participate in the process of developing, testing, and delivering complicated software, as well as witnessing the growth of the teams and the people in them. This job is much more than just writing code — it's always more about the people. At the end of the day, the only interface we all share is the human interface.

Let me show you some aspects of how we develop software products at LINE.

Facilitator rotation

There are many teams participating in LINE app development, and many of them have adopted some flavor of Agile methodologies. Our team has a facilitator that is responsible for organizing and leading Agile ceremonies, such as stand-up meetings, sprint planning, and retrospectives.

If you've ever imagined yourself as a software engineer buried in a mountain of code for months, you're not alone. I've been there, surviving on nothing but pizza and coffee, but this isn't always how it goes. Despite how it's been depicted in the TV show Silicon Valley, it's neither the whole truth nor a practical way to work. From my experience, I feel that being a team player is also very important: it would help a lot if you cared about the project and your team. Ask for help when you need some, and extend a hand when possible.

Being a facilitator is a mechanism to make you care about the project and the team: you might space out during a meeting if you are just a participant and crunching code, but you (to some level) have to care to be an effective facilitator. This also facilitates communication and understanding between team members: sometimes it can be difficult to ask questions, maybe out of fear of embarrassment. However as a facilitator, you are more expected to ask questions when trying to get a grasp on the broader picture of the project.

Random reviewers

Another practice we have is the random reviewer. For most pull requests (PR), we have two phases of reviewing. Of course, the PR should be reviewed by the code owners, but we also have a reviewer randomly selected. This reviewer, as a result, is not necessarily familiar with the specific part of the codebase. So this reviewer is generally expected to make sure the code has good readability and adheres to the style guide.

From the top down, this practice can help maintain a higher level of code quality. However as an individual developer, I am also grateful for it. It's easy to get lost in the details of a specific task, especially when trying to deliver such a complicated product. I appreciate the chance to see beyond my own field and learn from others' work.

But it should also be noted that this practice is not always observed. When facing an emergency, we might need to break some rules to fix the problem. I once heard that the severity of an outage is measured by the number of rules broken when fixing it. In the end, the rules are there to help us, not to bind us.

Code review is not the only way to share knowledge. Among the LINE client engineers, there is a review committee. Not only does it provide advice and feedback on the code, but every week, there is a session on code readability, best practices, and the many pitfalls when writing code. In addition, the weekly study session is also a great chance to learn from engineers near and far. Plus, when it's your turn to present in the study session, it's a great chance to systemize your knowledge and express your thoughts.

Demo

As an iOS developer, I always aspire to achieve the level of excellence that Apple represents in software development. In the book Creative Selection, Ken Kocienda, a former Apple engineer who was in charge of making the iPhone keyboard, described how software engineering at Apple relies on frequent and regular demoing sessions. You can sense the same spirit in the WWDC or hardware keynotes from Apple.

We also have a similar practice. When implementing a new feature, it's common practice to do a demo between Android and iOS clients, so we can find inconsistencies and bugs early. We also have a demo session with the planning and QA team to make sure that the feature is working, and can be verified to be working as expected.

Communication comes with miscommunication. However compared to text, voice, and even images, and videos, I find that live demos are by far the most effective way to communicate product details and keep everyone on the same page.

Pre-QA status check

Speaking of staying on the same page, a lot of tasks can be done within a sprint. Some need special attention during QA, some need attention from the design team, and some are just not user-facing at all. Having all the stakeholders present to go through the status of each task is a great way to reduce the risk of miscommunication and misunderstanding. A lot of the processes are of course automated, but in many cases, it eventually comes down to the team going through the tasks and explaining.

There is also a checklist to help us keep track of the many tasks during the release process. And this is not the only time we will see the word "checklist" in this article.

Checklists

In our pull request description template, we also have a checklist. Here resides often-forgotten tasks. I used to be quite strongly against checklists. For two reasons:

Since we are trying to solve the problem of forgetfulness, isn't a checklist just another thing to forget?
What stops someone (though not particularly anyone) from just checking the boxes without actually doing the tasks? Based on the unreliable nature of humans, I concluded that automation would almost always be a better solution.

Here's the problem: while I can yell that humans are not trustworthy all I want, I have to trust my colleagues. Alas, no one can do everything alone. At the same time, we cannot automate everything, either (at least not within a reasonable time). So, to solve the problem of human mistakes, we should not be trying to remove the human factor from everything, but rather encourage good habits and trust in the team. To that end, checklists are a great tool. It also helps that all the colleagues I have ever had the honor to work with are extremely trustworthy and responsible.

What's more, situations like releasing new versions or emergency bug fixes can be stressful. In that situation, a checklist can make me a much more reliable teammate.

Tea time

LINE is an international company, with a diverse group of engineers, and offices in many countries. When working in such an environment, it's essential to develop a trusting relationship with other team members. However it's kind of hard to do so if people in our team do not get a chance to even know each other well. And that is (in my opinion) why we have a dedicated tea time. The tea time is arguably for work, but most definitely not about work. We talk about everything from favorite games to dream houses. And I do feel that getting to know my colleagues on a human level helps me work with them.

Utterly human

To err is human; to forgive, divine. — Alexander Pope, "An Essay on Criticism"

I went into this job because I like to talk to computers. When talking to computers, the only question to ask myself is "In what way am I not like a computer enough?" It turns out that being a software engineer in a team is much more about being human than being a computer. As humans, we do not have telepathy, so we need to communicate. And all the ceremonies and rules are just ways to facilitate prompt communication. As humans, we are prone to making mistakes, yet we often forget the mistakes we have made in the past. So we set events and checklists to remind us to review and reflect regularly. And since we cannot manage everything by ourselves, we set aside time to get to know, trust, and care for each other. From this perspective, the software products we create are just like us: utterly human.