Coding Dojo is a practice where software engineers try to solve problems in a slower manner and in of full consciousness. Instead of rushing to the solution, engineers will take a step back and look at the problem’s nature. After truly understanding the problem, a solution will naturally appear.

On 15 November 2014, IMT Solutions in association with University of Science has hosted a simple Agile Coding Dojo for students majoring in Computer Science. Hiep Le, who has hosted many Agile Coding Dojo in IMT Solutions and in the Vietnam Agile community, was in charge of this session.

The problem  posed to students during the Dojo was named “Batman Application” with a faulted solution Batman that only runs in happy case.

You are given strings of different lengths. If the number of vowels are equal or more than 30% of the string length, then replace ‘iambatman’ for each continuous set of vowels.

Example: “a”->”iambatman” “baab”->”biambatmanb” “jokkr”-> “jokkr”

In the first session, Hiep Le instructed students to form groups of 7-8 people each, they need to:

  • Discuss the given problem.
  • Write acceptance tests for the problem.
  • Execute their tests on the provided solution.
  • Ask questions regarding to the problem.


Students were asking questions about the given problem

After 20 minutes, Hiep Le closed the first session by asking whether participants:

  • Only test the happy case.
  • Do the boundary testing on the exact 30% case.
  • Test the given string is empty or null?
  • Wonder about expected behavior:
    • if the given string contains special characters like ê, ơ, ư etc…
    • if the text has empty spaces in the begin or end.
    • etc

Participants were surprised at how a simple problem can have many hidden requirements and areas that require customer collaboration and teamwork communication to truly understand the big picture. Motivated by the experience, participants were excited to join the second session by re-writing the faulted solution that does not only fix the failing case but also meet:

  • Accuracy (does not use float to compare)
  • Maintainability (extract methods and rename variables)
  • Reusability  (Configurable threshold and replacing text)

After 30 minutes of hard working, several solutions were submitted. Even though none of them met all the expectations, many of them were promising and proved that participants had begun to understand what requires of a professional software engineer.