The year seemed to pass while I handled tasks in order of priority.
It’s a bit disappointing that I couldn’t spare enough time to polish or develop things at a relaxed pace because I was busy fulfilling top-down ASAP requests.

Automation or Project Completion

While creating a bot to handle issues, I thought about automating work.
However, our team leader said, “This is not about automation; it’s about properly completing the project.”
The issue-handling process is also part of the project, and we had overlooked it.

He was right.
But designing and completing a project while considering statistics and issue handling isn’t easy—especially during a busy year like this one.
Still, I want to reflect on the things I accomplished this year.

1. Building an Issue Response Process

One module I manage receives around 80 client issue requests per month.
So far, we’ve had a process where we manually ran scripts to respond to these requests, taking from an hour to a week.
While it didn’t take very long, the frequent context-switching made it costly.

One day, I was working on these tasks and got bored, so I built a Slack bot to make it more fun.
After wrapping up the tasks that week, I used some spare time to create the bot, which now handles client issues.

Benefits of the bot

  1. Saved 40 hours per month on issue handling (30 minutes * 80 requests).
    • I found out that the client didn’t request it more because of the slow response.
    • With the bot, clients requested more.
  2. Reduced client wait time by 80 days per month (1 day * 80 requests).
    • While this was idle time, having a process to respond quickly—even on weekends—was beneficial.
    • It’s not that client can’t work because it is just waiting time, but I established process that allows client to get a response right away even on weekends.
  3. Adding features to the bot became easy, so other modules’ function were also integrated.

2. Reporting Service Failures

We use Grafana to monitor services, but we don’t see it very often.
We receive alerts if module success rates drop below a threshold (e.g., 99.9%). For new modules, we started with the idea that there should be “no unknown 500 errors.”
To address this, We set up an AWS Lambda that sends Slack notifications when unexpected 500 errors occur, allowing us to identify issues immediately.

3. Designing Statistics

Extracting statistics from completed modules can be painful.
Sometimes, we had to dump databases or query a year’s worth of logs to answer once-a-year requests.
For new modules, We focused on designing statistics from the outset and developed a batch module for organizing them.

Tactical DDD

Continuing from last year, we’ve been developing with DDD (Domain-Driven Design).

This year, We

  1. Developed one module early in the year.
  2. Refactored one module mid-year.
  3. Built a new module at the end of the year.

Through these three projects, I deepened my understanding of DDD.

This year, I studied and summarized the tactical parts of Vaughn Vernon’s Implementing Domain-Driven Design

  1. Domain Events
  2. Value Object
  3. Domain Service
  4. Entity
  5. Aggregate

Even though reading summaries can give an “aha!” moment, team members had different interpretations of DDD concepts during development.
I shared my summaries within the team, which led to valuable discussions and personal growth in design skills.

1. Aggregate

Vaughn Vernon mentions that aggregates are the most ambiguous part of DDD.
This was also the most debated topic within our team.

We initially designed one module with an overly large aggregate, which felt like a code smell.
Studying aggregates further taught me the importance of size and criteria for dividing them.
Experiencing the downsides of large aggregates firsthand was a great learning opportunity.

2. Domain Events

Our team doesn’t usually use domain events.
However, after studying the concept and sharing it internally, I received feedback suggesting many areas where domain events could be applied.
While it wasn’t feasible to adopt domain events immediately due to project constraints, I learned to recognize situations where they would have been beneficial.

Team

I think our team collaborates well and operates efficiently.
This year, some of our team processes improved significantly.

1. Standardizing and Splitting Stories

We break tasks into stories.
This year, we standardized how we document development stories, reducing the time spent creating stories and ensuring no tasks were missed.
A standardized development story looks like this.

  1. Design the implementation.
  2. Write acceptance tests.
  3. Implement interfaces.
  4. Write scenario tests.
  5. Implement the domain.
  6. Implement use cases.
  7. Pass scenario tests.
  8. Pass acceptance tests.
  9. Retrospect.

Unnecessary cards are removed during the design phase.
For example, if only part of the domain changes without external impact, tests or interface cards can be discarded.
Clearly splitting stories made task distribution smoother.

2. Story Point Estimation

We previously estimated tasks in amount of time.
we switched out estimation to story points, which estimate based on amount of work.
With story points and team MH (man-hours), we now understand how many stories we can handle.

Interestingly, our rotating Scrum leaders tend to aim for maximum story points.

3. Priority-Based Schedulingbgh

We manage schedules by stacking stories in a backlog.
This year, we assigned priorities (high, mid, low) to stories and adjusted them during Scrum planning.
By focusing on urgent priorities first and aligning story points with sprint goals, we reduced the risk of over-planning or addressing less critical tasks first.

4. Bonus. Team Leadership

At year-end, I attended company training that included a week-long team project.
The project involved working with members from different teams.
In this training, many teams said they set up nights to complete their final projects. In the first meeting, I noticed the meeting didn’t go well, so I took the lead.

I led the team through design discussions, sharing plans, writing tests, creating interfaces, distributing assignments, etc.
This experience reinforced my confidence in both team-based work and leadership. It was fun being a leader for the first time outside my usual team.

Lesson of the Year is Doing the same work in the same way is boring.
I wanted to try new things but it was not easy.
Next year, I hope to work in a new way or on something entirely new for more fun.