Chinese Idiom Stories for Software Professionals: #08 Cut a Mark on the Boatside to Retrieve a Sword (刻舟求剑)

Take foolish actions without considering the changing environment.

This article is one of the “Chinese Idiom Stories for Software Professionals” series.

Story

One day, a man of the State of Chu was crossing a river by boat. Due to his carelessness, his sword which hung at his side fell into the water. Not in the least worried, he slowly took out a small knife and cut a mark on the side of the boat.

Someone on the boat asked him: “Why don’t you jump into the water at once to fish for your sword? What’s the use of making this mark on the side of the boat?”

He pointed to the mark on the side of the boat, saying unhurriedly: “There is no need to worry. My sword fell into the river at this marked place. As soon as the boat reaches the dock and pulls into shore, I will jump down from here to retrieve my sword.”

Meaning

To rigidly cling to an idea or approach without considering the reality of a situation.

Examples in Software Development

Software Testing (automated or manual)

Most readers of my blog are software testers, here I will use a specific example to illustrate the mindset of “Cut a Mark on the Boatside to Retrieve a Sword” in software testing.

Let’s say, all user stories have been implemented, the project manager is planning a round of system testing. The team has identified 500 test cases, with 5 testers and one tester completing 10 test cases each day on average, the project manager allocated 10 days to complete the whole task.

Does it sound familiar? This approach is completely wrong, and people conducting the above do not understand software development at all. Yet, I have seen this all the time in consultation.

Why? This is against the nature of software development. Putting aside the human factors, try to answer these questions (as the test manager/PM):

1. Do you want to find out the defects in this 10-day testing?
   Absolutely. I hope to detect a handful or more high-severity defects.

2. Do you expect the developers to fix those defects?
   Of course.

3. Will you re-test the new builds that developers claimed fixed the defects?
   Eh .., yes, only re-test those. (we might extend a few days on re-testing)

4. The fact, a simple code change (e.g. an extra comma in JavaScript) can cause new issues in unknown parts of the software. How can you be sure that those fixes won’t introduce new regression errors?
   Eh …….

Project Management

Many software project managers are fixated on software development activities following a perfect plan, e.g. Gantt Charts in MS Project. This is ridiculous obviously. A perfect working plan requires these: