DEV Community: Sohei Chikama

The Concept of Designing Retrospective

Sohei Chikama — Sun, 29 Sep 2024 10:31:39 +0000

I wrote this article intending to for the proposal to RSGT 2025, so if you don't mind, please consider giving a like to my proposal.

RSGT 2025 Proposal

As it's been a long since the last post, I would like to describe some about the Retrospective in Scrum, which I discussed deeply with my Agile Coach.

I shared this content with my junior engineer friend and he said it's worth paying me some drinks, so I am expecting that you would enjoy a lot if you are interested in Agile or Scrum

The Quality of Retrospectives Reflects the Quality of the Team and Ultimately the Product

Are you conducting retrospectives in your team?

When I ask this question to the developers in Scrum team, many respond, "We do it properly every sprint," or "We allocate time every other week."

However, when I ask what actually they do, I often find that they are merely writing down KPT (Keep, Problem, Try) and just sharing it among the team.

Retrospectives are activities that handle "Inspection" among the three pillars of Scrum: "Transparency," "Inspection," and "Adaptation." They also serve as activities to prepare for Adaptation.

The quality of this "Inspection" directly impacts the quality of the team and ultimately the product.

Therefore, simply writing down KPT and presenting it may be somewhat insufficient.

Scrum also has Sprint Reviews as a representative inspection event.

The Sprint Review is an inspection of the product, responsible for how to improve the product.

On the other hand, the Retrospective is an inspection of team activities, responsible for how to improve the quality of team activities.

I have summarized the representative inspection perspectives in a diagram based on what came to mind.

Looking at it this way, you can see that each event has a very large number of topics, and it's clear that just discussing them briefly won't lead to improvement.

To efficiently discuss these topics and ac## Designing a Retrospective

Designing the Retrospective

What does it mean to design a Retrospective?

Including retrospectives, most meetings have a purpose.

Purposes vary, such as brainstorming, information sharing, or deciding on measures to address immediate issues.

Whether the participants of the retrospective can smoothly reach that purpose depends greatly on the quality of the agenda and facilitation.

Elements like how to conduct the proceedings, what methods to use for discussions, whether to encourage divergence or convergence and how to draw conclusions are important.

From that perspective, considering the agenda and discussion methods to guide participants efficiently and appropriately towards the purpose is the idea of designing a retrospective.

To surely run an improvement cycle that enhances team activities, it's necessary to properly design each event and guide the team into discussions.

Although we won't touch on Sprint Reviews this time, the idea of designing events and meetings is useful in various situations, so please consider it if you're interested.

Phases and Tools

As we begin designing retrospectives, let's look at retrospectives from the perspectives of Phases and Activities.

Phases are, as the word suggests, stages of discussion.

In the design stage, we consider what steps to take in the discussion to efficiently reach a conclusion.

For example, if there are four phases—Sharing, Divergence, Analysis, and Decision-making—we examine questions like Is it sufficient to have one round each of divergence and analysis? Is decision-making necessary? How much time should be allocated to each?

While retrospectives have their own purposes, each phase also has a purpose, and the tools used to achieve the purpose of each phase are the activities described next.

Activities refer to what methods of discussion are used in each phase.

For example, KPT, which was mentioned at the beginning, is one of the activities used for conducting discussions.

Other activities that many of you may be familiar with include "Sailboat Retrospective," "5 Whys," "Brainstorming," and "Good/Bad/Ugly."

Each activity has its strengths and weaknesses, and it's necessary to consider combinations based on the team's situation, the phase of discussion, and the required time.

By combining appropriate activities for each phase, you can proceed with discussions more efficiently.

In this way, analyzing the timebox of the retrospective and the team's situation, and considering combinations of discussion stages (phases) and discussion methods (activities) forms the basis for designing a retrospective.

Moreover, this way of thinking can be used in regular meetings as well, so please try using it not only for retrospectives but also in workshops, presentations, and various other situations as needed.

Note that the quality of the design can vary greatly depending on the number and maturity of the activities you have at your disposal.

If you're not familiar with many activities or don't know how to conduct them, please consider reading 'Agile Retrospectives: Making Good Teams Great' listed in the References section.

It introduces a large number of tools.

The Five Phases of a Retrospective

Now, you might be unsure where to start if you're suddenly told to design a retrospective.

Don't worry. In Scrum retrospectives, there is a commonly used framework called the "Five Phases."

This is the idea of dividing the retrospective time into five phases and combining activities in each to lead to conclusions.

Below is a simple summary of these five phases. The time in parentheses is a guideline for time allocation when designing a one-hour retrospective.

Set the Stage - Get Ready for Discussion (within 5 minutes)
Collect the Data - Gathering data (about 10 minutes)
Generate Insights - Analyzing data (about 30 minutes)
Make Decisions - Deciding what to do (about 10 minutes)
Close the Retro - Closing the retrospective (within 5 minutes)

In this framework, you prepare for discussions, gather discussion topics, discuss the collected topics, decide what to do, and get ready to move forward.

Now, let's explain each phase.

Set the Stage - Get Ready for Discussion

In this phase, we have to get ready so that all participants can discuss comfortably.

It is important that all participants can participate in the discussion. However, in unfortunate retrospectives, sometimes a few strong-willed individuals dominate the conversation, or those who miss the initial opportunity to speak remain silent until the end.

This phase is intended to have all participants feel, "We are about to participate in a discussion," and "It's okay to speak up here," and it serves as a place to establish and confirm rules for that purpose.

Having everyone participate in the discussion and express their opinions in the place where the team's direction is decided not only gathers multiple perspectives but also leads to a sense of ownership when implementing the improvement plans decided in the retrospective.

This phase tends to be overlooked, but unless time is severely constrained due to delays, please make sure to carry it out.

What to do in this phase greatly depends on the team's maturity.

I will introduce two activities for different maturities.

Check-In

For example, if the team has high psychological safety and each member can actively express their opinions, it's fine to just have them say a few words.

Originally, check-in is an activity to help participants focus on the retrospective, so the rule is to have them share what they expect from the retrospective or their current situation, but there's no need to stick strictly to that.

Questions like "Share your thoughts on this week's sprint in one word!", "Describe your current mood in 20 characters!", or "Tell us what you had for lunch today and your thoughts on it in one sentence!" are sufficient.

This isn't because we want to know the answers to these questions or to engage in team bonding; it's more like a warm-up to create an atmosphere of "I'm about to speak up" and "I'm going to express my opinion."

It may seem meaningless, but whether or not you do this activity can significantly affect the liveliness of the discussion.

Even if it feels silly, please make sure to do it.

In my company, we often start by doing an activity where each person places their name on the "Wheel of Emotions" and shares briefly why they chose that spot.

Team Agreements

On the other hand, in teams where some strong-willed individuals tend to dominate the conversation, start by establishing and confirming discussion rules.

Specific rules might include: "Be mindful so that everyone speaks an equal amount," "Do not interrupt and listen until someone finishes speaking," "If you feel it's hard to join the conversation, give a signal," "If you talk for more than one minute, check if other members have opinions or questions," and "Do not take away the speaking opportunity from someone the facilitator has designated."

These rules can be decided by the facilitator or Scrum Master, but it might be good to take some time during the retrospective to discuss them.

If they are agreements decided as a team, both members who tend to talk too much and those who are not good at speaking can participate in discussions with mutual understanding.

Also, if there are members in higher positions, it can be effective to ask them in advance to moderate the frequency and intensity of their comments.

Collect the Data - Gathering Data

Once all participants are ready to speak, the next step is to gather seeds for discussion.

When you think of data, you might imagine quantitative elements like completed story points, man-days, or the number of PRs. However, the data referred to here also includes qualitative elements such as emotions, opinions, and events.

Posting KPTs (Keep, Problem, Try) is also one of the data collection activities. KPT is a tool that handles everything from data collection to decision-making in one go, but at this point, it's better to treat "Try" as something like "things we think we should do."

Specific data examples include the following:

Quantitative Data and Tools for Obtaining Them

Transition of completed story points: Jira, etc.
Lead time of development activities (※1): Findy Teams, etc.
Values of 4 Keys (※2): Jira, Findy Teams, etc.
Actual working hours (※3): Team calendars on Kanban boards, groupware, etc.

※1 From initiation to design creation, from design completion to development start, from development start to PR creation, from PR creation to merge, from merge to deployment, etc.

※2 Deployment frequency, change lead time, change failure rate, time to restore service

※3 Total working hours within the sprint, excluding vacations, meetings, Scrum events, etc.

Qualitative Data and Representative Activities

Feedback on team activities: Keep/Problem/Try, etc.
Feedback on team status: Good/Bad/Ugly, Sailboat Retrospective, etc.
Events within the sprint: Timeline, etc.
Emotional feedback from members: Mad/Sad/Glad, etc.

Of course, it's not realistic to collect all of this data, and too much information becomes noise. Please have the facilitator decide what data to collect and how, after confirming in advance what the Scrum Master and team members want to discuss.

Also, one point to keep in mind is that the most important part of a retrospective is the discussion and analysis that follows. Therefore, using tools that automatically collect data or gathering KPTs in daily activities are very effective ways to reduce the time spent on data collection.

Actually, it was repeatedly pointed out during mentoring meetings with a Scrum Trainer, and we created a board to regularly collect timelines and emotional/activity feedback.

Also, in the team I participated in, we prepared a space called Found and Resolved, which was set up to put sticky whenever someone noticed something they wanted to discuss with the whole team.

Generate Insight - Analyzing Data

Next is the data analysis phase. As mentioned at the end of data collection, this phase is the core of the retrospective. We bring together the collective wisdom of all team members to analyze the collected issues and explore solutions.

Selecting Topics to Discuss

Before starting the data analysis phase, the first thing to do is select the issues to discuss. Each member has their own sense of issues, and various topics come up during data collection.

However, since the time available for discussion and for implementing improvements is limited, it's necessary to narrow down the topics to decide which problems to solve or which good points to further enhance.

My recommended methods for narrowing down topics iare Dot Voting and Heat Maps.

Dot Voting

Dot voting is a commonly used method, so many of you may already know it, but I'll explain it for just in case.

In Dot Voting, you decide on the number of votes per person (e.g., 3 votes) and vote on the topics collected during data collection that you want to discuss. Limiting the number of votes allows each member to prioritize topics.

The topics that receive the most votes become those with high team interest, and the impact when improved becomes greater. Dot voting can be done in a short time and has the advantage of simplicity and easiness of understanding.

However, one caution is that when conducting dot voting, you need to ensure that it's not apparent who voted for what, such as by color or name.

If voters are identifiable, there's a possibility that votes may be skewed due to power balances within the team. To select topics that all team members can discuss on an equal footing, use anonymous dots of the same color.

Heat Maps

Personally, I recommend Heat Maps over Dot Voting. It's an extension of dot voting, where you vote with as many dots as you like, up to a set limit, on the topics collected during data collection that you want to discuss.

The number of dots represents your level of interest in that topic. For example, if the maximum is 3 votes, it can be interpreted as follows:

1 vote: Interested
2 votes: Want to discuss
3 votes: Really want to discuss

After voting, tally the number of dots as in dot voting, and start discussing the topics with the most votes in order.

The good thing about heat maps is that they reflect the strength of each member's will.

In dot voting, topics that aren't of much interest may still receive votes, but in heat maps, the level of interest affects the number of votes.

By using heat maps, topics that may not have gained much consensus but are very important to certain members also get attention, allowing problems noticed only by some members to be selected for discussion.

Deepening the Discussion

Once you've narrowed down the topics to discuss, move on to the discussion. Share opinions and ideas on the selected topics, and share what you'd like to try or do.

You can conduct the discussion freely until a conclusion is reached, but by using tools like Fishbone Diagrams, 5 Whys, or Lean Coffee, you can proceed more efficiently.

I myself often use Lean Coffee in 1-on-1s and regular meetings, so I'll explain Lean Coffee here.

Lean Coffee

Lean Coffee is a method used to discuss many topics by setting timeboxes. By following the rules below, you can perform analysis and idea generation in a short time.

Divide 10 minutes into three segments of 5 minutes, 3 minutes, and 2 minutes.
At the end of the first 5 minutes, pause the discussion.
If you feel satisfied with the topic, show a 👍; if you still want to discuss, do nothing.
If the majority shows a 👍, move to the next topic; otherwise, continue the discussion.
Do the same for the remaining 3 minutes, and after the final 2 minutes, move to the next topic unconditionally.

By proceeding with the discussion in this way, you can talk about up to 6 topics in 30 minutes, or at least 3 topics. Also, if you come up with 2 TRY ideas for each topic, you'll generate between 6 and 12 TRY seeds from the topics.

As a side note, when conducting Lean Coffee, it's recommended to assign a scribe. By visually tracking the flow of the discussion, it's easier to generate constructive TRYs.

Make Decisions - Deciding What to Do

After deepening discussions and generating various TRYs (things we want to try), we finally decide what to implement to improve the team.

Even though TRYs have been raised during the discussion, it doesn't mean that the subsequent improvements have been decided.

We cannot implement all the TRYs that were raised, and the TRYs that came up during the discussion are not necessarily executable as they are.

In this phase, we primarily conduct the following discussions and decisions:

Decide which TRYs are most important for the team
Refine TRYs to make them executable
Assign TRYs to team members
Manage the TRYs

By going through this phase, the TRYs become executable as follows:

Let's explain each of these.

Decide Which TRYs are Most Important for the Team

Selecting appropriate topics and engaging in active discussions can result in many TRYs. However, it's not realistic to execute all of them.

Trying to implement many TRYs simultaneously can lead the team to face many changes in the next sprint, causing fatigue. In the worst case, the motivation to execute TRYs may gradually decrease, turning the retrospective into just a place to propose improvements without action.

To avoid such situation, I recommend you to utilize tools like dot voting or heat maps to decide which TRYs to implement in the next sprint at the beginning.

Refine TRYs to Make Them Executable

As mentioned earlier, the TRYs generated during discussions may not be directly executable. To make the selected TRYs executable, refine them by clarifying the wording, creating subtasks, and adjusting the scope.

When refining TRYs, it is recommended to compare them with the criteria of SMART goals.

A SMART goal is a commonly used criterion for goal setting, derived from the initials of the following five words:

Specific: Clear and specific
Measurable: Progress and results can be measured
Attainable: Realistically achievable
Relevant: Appropriate for solving the problem
Time-bound: Has a clear deadline or time frame

For example, suppose the following problem and TRY have been raised:

Problem: Pull requests are piling up, causing many conflicts

TRY from the discussion: Schedule time for pair reviews

This TRY is not necessarily executable as is. Let's refine it from the perspective of SMART.

Specific: The action itself is clear, so no problem here.
Measurable: Frequency and duration are not specified, making it hard to measure. For example, adding the words "1 hour daily" would be better.
Attainable: Scheduling between reviewers and reviewees is necessary. For instance, creating a subtask to block 1 hour on own calendar after the Daily Scrum (DS) can increase feasibility.
Relevant: Securing review time helps prevent PR backlog, so it is appropriate for solving the problem.
Time-bound: There's no set deadline. For example, "Continue for two weeks and evaluate the effect in the next retrospective" makes it clear.

By refining the TRY in this way, we get the following specific TRY and tasks:

Problem: Pull requests are piling up, causing many conflicts

Improvement (TRY): For the next two weeks, schedule 1 hour after DS for pair reviews, then discuss whether to continue afterward

Tasks

Register the schedule in the calendar
Add a pair review request to the end of the DS agenda
During each DS, ask if anyone needs a pair review
Discuss whether to continue after two weeks

Assign Responsibility

To execute the refined TRYs, the next step is to assign responsibility. Clearly define who is responsible for completing the TRY and who will carry out the created subtasks.

A common issue in retrospectives is that improvement ideas are proposed but end up not being executed.

Deciding who is responsible at this stage is crucial to cultivate a habit of the whole team taking responsibility for improvements and preventing the retrospective from becoming a mere formality.

In a team I previously participated in, we established temporary roles called "〇〇 Police" (e.g., Review Police, Pair Programming Police) to check whether the team's decided improvement plans were being executed and to prompt action.

Having fellow team members gently remind each other made it easier to implement improvement plans without resistance, which I found to be a very effective approach.

Manage the TRYs

This step is not mandatory, but managing TRYs had a significant positive effect on improving team activities.

Even after refining the selected TRYs and assigning responsibility, sometimes the improvement plans decided a week or a month ago get sidelined due to daily tasks.

To avoid such situations and ensure that improvements are executed, I recommend managing TRYs on a Kanban board and checking progress during the Daily Scrum (DS).

Regularly reviewing the progress of TRYs and tasks from the previous sprint to see if team activities are improving was very effective.

Close the Retro - Closing the Retrospective

Once you've decided on the improvements to implement in the upcoming sprints, the final step is to close the retrospective.

In this phase, you record what the team has learned, solidify the improvement plans, and express gratitude to the participants and facilitator.

The main activities are as follows:

Reflecting on the content of the retrospective
Moving TRYs and tasks to a visible place on the Kanban board (including transcribing them to the TRY Kanban if you're using one)
(For offline meetings) Taking photos of whiteboards or sticky notes
(For offline meetings) Tidying up the venue
Expressing gratitude to the participants and facilitator

I'd like to introduce two activities that I personally enjoy.

Retrospective of the Retrospective

While a retrospective is an activity to improve team practices, the retrospective itself is also subject to improvement. By reflecting on the retrospective at the end, you can conduct future retrospectives even more efficiently and effectively.

In a Retrospective of the Retrospective, each member writes down what went well and areas for improvement at the end.

By candidly sharing feedback such as "I couldn't express what I wanted to say," "There were moments when the discussion stalled," or "The connection between phases was weak," you can apply these insights to the design of the next retrospective.

Circle of Gratitude

This activity is particularly effective in quarterly retrospectives. It's also very effective in overall retrospectives held at the end of a project or release.

The method is very simple: participants take turns expressing gratitude to the team and each member.

Procedure:

The first person expresses gratitude to the team and to someone (or everyone) in the team.
The person who just spoke nominates the next person, who then expresses gratitude to each member in the same way. (You can nominate someone who you expressed gratitude in step 1.)
Once the last person has finished expressing gratitude, declare the completion of the retrospective.

Retrospectives are held to conduct continuous improvement, and by concluding with expressions of gratitude to your colleagues, you can start the next sprint on a positive note. This also leaves a positive impression of the retrospective itself and the overall improvement activities.

Conclusion

This post has become quite lengthy, but that concludes the discussion on the concept of designing retrospectives.

Retrospectives are one of the representative Scrum events, and I believe they are often conducted in a way where people "just try doing it without really understanding it."

Since the goal of Scrum is to increase product value through continuous hypothesis testing and improvement, the focus tends to shift towards improving the product or service itself, such as backlogs and sprint reviews.

However, at the same time, the core of Scrum is the team, and improving the quality of the team ultimately leads to the quality of the product.

If this article has piqued your interest in retrospectives, I encourage you to take this opportunity to design the retrospective event anew.

Additionally, if you'd like to discuss or ask questions about this article, or if you'd like me to design and facilitate a retrospective for your team, please feel free to contact me at the email address below.

Email: munchkins.hands@gmail.com

Lastly, as mentioned at the beginning, I wrote this article intending to for the proposal, so I really appreciate if you can put a like to my proposal.

RSGT 2025 Proposal

Thank you for reading to the end.

References

The Five Phases of a Successful Retrospective

Are you an Elite DevOps performer? Find out with the Four Keys Project

Lean Coffee Retrospective

Agile Retrospectives, Second Edition: A Practical Guide for Catalyzing Team Learning and Improvement (This is link to Amazon, but not for promotion or affiliates.)

Why we used Typescript instead of Java on Serverless

Sohei Chikama — Mon, 03 Feb 2020 15:15:59 +0000

NOTE about this article

Since this is related to our business application, I do not write all the things happened to our project in detail and some backgrounds are manipulated. However, I believe that the tech-related parts are all the fact and I tried to write as precisely as possible. I hope this article will help you gain some knowledge and solve your problem with the serverless shift.

This article was copied from my personal blog and not plagiarized from some other place.
Why we used Typescript instead of Java on Serverless from Junks, GC cannot sweep

Introduction

Serverless is one of the most modern and highlighted software architecture and recently more and more developers are starting to using it in their own application or services.

I also am loving it a lot now and I cannot think of getting back to the self-managed server model anymore.

Basically, if your application is well designed for scaling and distributing, most of the feature we rely on the server application has been lost, I believe.

So these days, I always encourage serverless if asked about the architecture or designs of web service.

Btw, since it is a totally different approach from the traditional development method, Serverless requires us to refresh our knowledge and review the tech stacks we've been using.

What language we should use also is one of the things we need to review.

Finally, we started to use *Typescript and have been working with it for more than 1 and a half years.

And, as just a personal opinion impression though, it was much nicer than we expected it to be.

So I would like to write what was a problem with the old tech stack and what was good after switching it to Typescript.

Why we needed to give up Java

Before talking about the reason for choosing the Typescript. I would like to explain the reason why we gave up the previous tech stacks with one of the most excellent languages, Java.

--------------
NOTE

In the first place, I'm an enthusiastic Java Lover and my Mother Tongue also in Java. (Java 4 or 5, when there was no generics feature.)

I have studied about the JVM and was inspired a lot from it as well. I guess it was made by god.

So here I do not mean to despise or insult Java at all.

Any comments or complaints about Java are not welcomed, just it didn't work well with serverless at the moment.

---------------

Ok, sorry, let's go ahead.

We’ve been using Java as the primary language for our service for a long time and we actually know that Java has a lot of advantages like

Platform-Free
Well designed JIT compile
Excellent GC
Well-structured grammar
Type strong
Supports functional programming recently
Having a lot of libraries
Trustable communities.(Not Oracle, but developers community)

and etc..

We really appreciated it and rely on them a lot.

However, when we tested our code with serverless, we found that Java is not too good to be running on the FaaS service such as AWS Lambda.

The reasons are the following.

The overhead to launch the JVM is not ignorable.
Moreover, our primary framework Spring took more time for launching containers.
The final package of source code is relatively large. (Sometimes more than 100MB)
Hard to proxy the requests without using web framework when the number of functions increased
G1GC or JIT compile not works well since the container stops very shortly
Can not enjoy the benefit of the platform free since it always running on EC2 with Amazon Linux image. (Not cons, but just reduced the reason to use Java)

All the problems listed above were so annoying, but here I wanna explain the most troublesome one of the above.

Cold Start of Lambda is too troublesome

The most troublesome thing we faced at first was the overhead of the cold start. Yeah, I guess most of the serverless developers may have faced the same issue.

We used AWS Lambda for computing and AWS Lambda launches the container every time a request comes from users.

Once it is launched, it reuses the same container instance for a while, but in the initial launch, it needs to launch the Java Runtime environment and all the necessary web container or environments of frameworks.

Additionally, one container can be used to handle just a single request and cannot be used for multiple requests concurrently even though your application is ready with hundreds of request threads in your thread pool. It means that when several users send the request to the endpoint at the same time, AWS Lambda needs to launch another Lambda container to handle the other requests.

It was so troublesome actually since normally we cannot estimate the number of concurrent requests and hot standby mechanism doesn't work. (even if we make it somehow.) Eventually, it will force users to wait for several seconds to open the page or process the request and we were sure that it will surely degrade the user experience.

After seeing how the cold start is annoying, though we’ve already had a lot of codes written in the past several years, finally, we gave them up all and switched to use another language.

Why we chose Typescript

Actually, it is a bit shameful though, we’ve decided to use the Typescript from a really early phase without deep thought or comparison with other languages.

However, honestly, we have no choice of using other languages supported by Lambda from the beginning other than Typescript under that circumstance.

At first, we have no choice to use dynamic typing languages. The service and code are supposed to be running, supported, maintained and extended for a long time by variously skilled developers. So we would not like to use the dynamic typing languages for serverside.

Thus, Python and Ruby were out of options.

C# and Go have a totally different character from the language we (and other teams) were working on and it may take some time for other newbies to catch up.

Of course, we all were aware that these days those 2 languages, especially Golang is winning the share gradually thanks to its nature.

However, the arch change was a too immediate mission and we didn’t have much time to catch it up for ourselves as well. Thus, though those 2 languages were fascinating for us, we gave up using those langs.

Benefits of using the Typescript

So finally, we have decided to use Typescript.

The benefits of Typescript are as the following.

Type Strong
Much small size package
Super fast launch overhead
Able to reuse the knowledge of javascript and Java
Node libraries and communities are awesome
Suitable for functional programming even compared with the javascript
Able to write well-structured codes with Class and interface

As everybody knows, static typing is quite an important factor for the long-running project like B2B so I do not write much about it here. Here I wanna explain how the Typescript worked well with. With other features of the typescript, the type really works well more than we expected.

Less overhead to launch with small packages

Probably this is the most important factor to switch from java to Typescript in serverless. (Other benefits are almost about the benefit of using the Typescript itself)

As mentioned in the previous part, Java has overhead to launch the JVM and DI/Web container for the framework.

Additionally, as the nature of Java, it has the following weak point to be used in the AWS Lambda.

Typescript doesn't have those weak points and it resolved our concerns.

Multithreading and its eco-system

Multithreading is a powerful functionality of Java and it really helps us implement the high-performance codes.

Even the JVM itself is using it for the garbage collections to provide great performing runtime.

(See G1GC or JIT Compile)

However, you will find it takes from 100s milliseconds to several seconds to prepare for all the thread used in the container.

It is small enough and ignorable for the ordinal architecture like client-server running on EC2, but totally not ignorable for serverless applications which is running on the FaaS like Lambda.

Typescript is based on the nodejs and it only supports single thread by default. (Async or Sync is just controlled by call stack, not by thread)

Thus, the time to launch it is much short than Java with modern frameworks.

Big Package Archive

In serverless, normally, a small-sized package is preferred.

When the lambda container is launched, the container downloads the source code from the AWS managed source bucket in S3.

Time to download the S3 is normally small, but not ignorable if it is 100MB or 200MB.

With nodejs, the code size of a package could be relatively small compared with Java.

Honestly, I am not too sure why it is even now, but probably for the following reasons. (Please teach me in a comment if you know more.)

Java frameworks are usually comprehensive and can contain a lot of dependent libraries to cover everything, but javascript framework or libraries are more like on-the-spot and doesn't contain unnecessary files so much.
Javascript can write multiple modules or functions in one file and can maintain it with less effort, but Java requires to design the classes and interfaces with multiple files to write maintainable and well-structured code.

Actually, when using Java, the packaged jar was nearly 200MB at the biggest.

However, with using the nodejs, it could be reduced to 35MB+ at last.

It was partly because we tried to reuse the Spring Tech stack in the previous arch.

However, even after removing the unnecessary dependency and optimization, a package for one function still required 50MB.

Able to use the knowledge and eco-system of javascript

As we have been working on the web service, we have some kinda stacks of knowledge about javascript and nodejs.

Through the era of Jquery to the modern javascript like React or Vue, we’ve already learned the pros and cons of it and have obtained some know-how to write good code in javascript.

Typescript is a kinda extensive language of javascript and will be transpiled into javascript at last.

Therefore, many of the idiom or grammar is extended from the javascript and we could easily start to write the code without many preparations.

Additionally, most of the useful libraries are providing its type definition for the typescript so that we were able to enjoy the benefit of nodejs eco-system as well.

Works well with the functional programming paradigm

Functional programming is quite an important paradigm when we are talking about the tech trend these days.

It will let you write simple, testable, less-dangerous and stable codes with its nature.

AWS Lambda always requires us to get rid of the state from our code. Functional programming is requiring us to isolate the side effect or state from the functions and this idea surely is making our codes for Lambda more maintainable.

Basically, as John Resig told in Secrets of the JavaScript Ninja, javascript is supporting functional programming from the beginning.

It treats the Function as the first-class object and jquery also were supposed to be written in a functional way as well.

However, plain javascript is a dynamic typing and it sometimes introduces some difficulties to write good functions.

The variety of functions we can express with a single primitive type is quite limited and using the Object type for the arguments/return value is sometimes troublesome.

With typescript, we can specify the type of arguments or return value.

Additionally, following functionalities lets you write the code more safe, simple and expressive.

Type: Lets you distinguish the common type and its aspects such as string and UserId or Promise and Either.
Interface/Class: Lets you organize the sets of the arguments/return type as suitable for the context in the service.
Enum: No explanation necessary I guess.
Readonly: Lets you make your objects immutable.
Generics: Lets your functional interfaces be more expressive.

Typescript has more advantages for the functional programming, but do not mention them here all. (Partly because it's the advantage of javascript rather than Typescript..)

Please try it and enjoy your discoveries.

Able to reuse the best practice we used in Java

Once you see the tutorial of the typescript, you would find it is quite similar to the Java or Scala.

We’ve been trained how to write good code in Java through our long journey with them to some extent.

We were aware of how we should design the classes and interfaces, how to use enum efficiently, how to make the stream API maintainable in Java and it was not the thing we can throw away instantly.

Thanks to the similarity of Typescript and Java, we could easily take the previous practices over to the new codebase.

Typescript supports the interfaces, classes, access modifier, and readonly properties(equivalent to the final of property in Java) and It actually helped us a lot to reuse the best practices we learned in Java including Object-oriented programming practices and the Design Patterns. (FP and OOP are not antinomy and can be used in the same project, I believe. )

If we would have chosen Python or Ruby, probably we needed to struggle again to find how to apply the practices into the new language for a long time,

(Actually, of course, I know it’s a lot of fun, but not for the time in hurry arch change)

Of course, we didn’t do the copy-paste of the logics in the existing java classes.

However, even though we re-wrote them with 80% from scratch, it didn’t take much time to write it again with acceptable quality.

Conclusion

We are still new in the journey of Typescript and needing a lot to learn, but already found a lot of benefits of it and we really are enjoying it.

If asked now, probably using the Golang can be an option, using the Micronauts with GraalVM also can be an option or maybe there can be more options we can choose. However, I am really satisfied with the typescript so far and believe it is one of the best options we can choose in serverless.

Of course, already have faced some difficulties with Typescript and serverless like how to do the batch processing with relatively slow language, how to do the concurrent computing or distributed processing, how to make the workflow, how to overcome the timeout of API Gateway or how to ensure the data consistencies.

However, all those things are the most interesting things for us, geeks, to resolve.

Actually, we already have found some practices and have overcome them. I will write it in the near future.

If you are struggling with Java on serverless and losing hope for serverless, I strongly suggest you consider Typescript. I can promise that it will work better than you expect it to be.

Thanks for reading through this long article. I am happy to receive your comment or contact if any.