Design Theory: progress bar embedded percent development design

This is a content of the HCI human-computer Interaction group in watercress, as follows:

To test an application, there is a function:
A task is created that contains a number of subtasks under the task, "Start button, there is a Progress status monitoring window, which first shows a progress bar running forward, the progress bar is embedded with the corresponding percent complete, after the progress bar, there are two time related numbers: The time spent, the remaining time.

Because the program was done entirely for the Windows platform, the tester reported the bug and asked the developer to take the percentage of the progress bar, taking into account the fact that the Windows interface style advocated no embedding of numbers within the progress bar.

Here is a summary of the dialogue between the two sides:
Development: Why do you want to get rid of percentages? This is for the user to see clearly.

Test: First of all, Windows interface style does not advocate the percentage of the progress bar embedded, followed by the progress bar there are not two time related figures, the percentage is to gild the lily.

Development: The percentage within the progress bar tells you the progress of the task, and the next two time data tells you what time it takes and what time it takes, which is two different things.

Test: Time is not the progress of this task I do?

Development: You completely confuse the concept, the time schedule is the whole time overhead situation, the task progress is all subtasks, the different concept

Test: But from the user's point of view, I only care about how much time I have to do this task, and how much time I need, I don't care if you do a few tasks or how much a mission does.

Development: I think the percentage within this progress bar is useful to users, and you completely confuse the concept of time schedule and task progress.

Test: Did I confuse it?

Development: For example, you build a pyramid, expected 100 days to complete, the first 99 days you do nothing, but your time is up to 99%, and the task progress is 0%, the last day you finished all the make, so your task progress from 0% to 100%, and the time schedule is from 99% to 100%, You get it? It's two concepts.

Test: OK, so first of all why give the user these two conceptual data? Isn't that more confusing? and second and most important, even if your progress bar shows the progress of the task, it's not contradictory to take the inline percent number off.

Neither side can convince each other that the problem is hanging on (of course it's not a function or stability issue that will affect the release of Germany).

< —————— I am the divider —————— >

This is a common example in the real world, development and testing are Yikou called "users", it seems that they are "user" incarnation, the study of the user's "experts." But in fact, there is not much action to be put into validating the user's needs and ideas. As Kent.zhu here mentioned: "This era, what is missing, the only thing that is not missing is the experts!" "We don't need experts, we don't need any ued (edu or due), what we really need is to ask the user to come, make a cup of tea, and listen to what they want," he said.

In addition, the progress bar shows the percentage, and the value of this percentage does not represent the time remaining, nor does it represent the number of tasks that have been completed or remaining, and it can only represent a percentage (the time spent and the percentage of time remaining or the percentage of completed and remaining tasks). The three quantities I mentioned above are the same, and they refer to percentages.
If you want to show that percentages and progress bars are duplicates, and that the remaining tasks and estimated time remaining are additional references, they are all a factor in this percentage.