![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rPriska 2024
Most software engineers aren't really engineers because they like to talk. The people who are true engineers use numbers and images in their discussions, not rhetoric.
If you are talking to an engineer, you must only point out the direction of thinking. If you are explaining something to a manager, you must methodically cut off all possible ways of any incorrect understanding.
I mean not simple misunderstandings, but the special managerial ability to confirm their own hopes with facts that contradict them.
Such texts are time-consuming. I spent about 2 minutes thinking out a rough idea of the Agile Tnakh explanation and several hours adapting it to the managerial level of thinking.
I have mentioned the Agile Work Creeping in the previous part The Agile Tnakh Explained / 23 kB / 2024-01-16. This post closes my last debt.
The Agile Work Creeping is obvious to engineers. You cannot save money on quality in one place and get no paybacks in another. Bad software quality is paid for by the users.
This is not a subject for long discussions; this is only a question of measurements, estimations and informed decisions.
I cannot share something real, but we can look at a simple model.
There is some software that reads in some data from an external system, presents it to a user, gives him a possibility to adjust data manually and then confirm it. The user's conformation starts further data processing.
You are a quality engineer, and you get an error report. You find out that the data processing algorithms assume that all numbers are in American format ("2.3"), but they do not recognize German format ("2,3").
If the data reading process gets data from a German source, the further data processing fails because the numeric fields in the data confirmation dialog contain commas instead of periods.
Then you take a sheet of paper and draw the following diagram.
Please note that there are many kinds of diagrams that can describe the same behavior, but it is better to use pen and paper instead of wasting time playing with sophisticated tools. These tools are more suitable for other tasks.
You read the design documentation, take another sheet of paper, and draw the new version of the same process.
Then you take your diagram and go to the software development department.
Please note, this diagram represents only one of many possible solutions. There are usually several different ways to solve the same problem, and the true engineers discuss them all at the same time in order to choose not the solution they like, but the solution that is optimal for implementation.
Sometimes you downgrade some elements of a perfect solution to make it cheaper. Sometimes you persuade your manager to extend the project budget to get significant quality improvements.
I'll mention here a short explanation from my notes from another project. [ itSotWC::2024-01-16_1, itSotWC::2024-01-16_2 ]
Managers and politicians are one-dimensional beings: "Five is better than three."
Scientists are two-dimensional: "This is not a linear growth. This is an exponent."
The people who have still not lost their common sense are three-dimensional: "Yes. I see your chart of recent economic growth, but my wallet says that you have forgotten about inflation."
Teachers cut off the child's "but"-dimension and flatten his thinking. (The modern education system is today very effective.)
Engineers are forced to routinely perform multidimensional optimizations. They must simultaneously consider many different parameters. A person who cannot hold his grip on many dimensions is not a true engineer.
By the way, we have reached the software development department and found his manager. He says that the new feature will cost 100 man-hours. It is a waste of time to implement it. The German data is rarely read, and a user can get an error message and change numbers manually himself.
You return to your workplace, open the latest version of your software, load some datasets with errors, perform some tests by taking notes, and estimate the average correction time to be about 5 minutes.
Then you take a pen and add this information to your diagram.
Then you open a new spreadsheet and write:
Then you look into marketing data and make the following table using 3 conditional formats:
- green background in case the total user time waste is less than the error correction budget, cell "$B$2";
- orange for time waste from 100% to 1000% of the error correction budget;
- red for the time waste above 1000%.
Then you call your boss and arrange a meeting with the development and marketing departments.
I would say, this is a very optimistic example. Usually, work creeps from green to red much more quickly.
Of course, it is impossible to make such estimations in a real agile project.
First of all, the quality assurance department is replaced with agile testing.
The second problem will be the numbers you will get, if you try to measure the real volumes of work creeping. Even the most optimistic estimations without consideration of full work blocking would be very impressive.
Many years ago, at the times when incompetent people doing a bad job didn't yet know they were excelling in Agile, I was sitting at a conference, and a speaker was telling the audience that software requirements are not needed because they are difficult to define and hard to negotiate.
He was not the preacher of the Agile Age, just its prophet. Modern agile experts would call him a formalist and a retrograde.
We had left the room. A brilliant legal expert who has written some books about software development contracts muttered with a devastated expression on his face, "I don't understand… I don't understand who could agree to such terms… This is a sure loss… Hm… No! I don't understand…"
The Agile Work Creeping
Most software engineers aren't really engineers because they like to talk. The people who are true engineers use numbers and images in their discussions, not rhetoric.
If you are talking to an engineer, you must only point out the direction of thinking. If you are explaining something to a manager, you must methodically cut off all possible ways of any incorrect understanding.
I mean not simple misunderstandings, but the special managerial ability to confirm their own hopes with facts that contradict them.
Such texts are time-consuming. I spent about 2 minutes thinking out a rough idea of the Agile Tnakh explanation and several hours adapting it to the managerial level of thinking.
I have mentioned the Agile Work Creeping in the previous part The Agile Tnakh Explained / 23 kB / 2024-01-16. This post closes my last debt.
The Agile Work Creeping is obvious to engineers. You cannot save money on quality in one place and get no paybacks in another. Bad software quality is paid for by the users.
This is not a subject for long discussions; this is only a question of measurements, estimations and informed decisions.
I cannot share something real, but we can look at a simple model.
There is some software that reads in some data from an external system, presents it to a user, gives him a possibility to adjust data manually and then confirm it. The user's conformation starts further data processing.
You are a quality engineer, and you get an error report. You find out that the data processing algorithms assume that all numbers are in American format ("2.3"), but they do not recognize German format ("2,3").
If the data reading process gets data from a German source, the further data processing fails because the numeric fields in the data confirmation dialog contain commas instead of periods.
Then you take a sheet of paper and draw the following diagram.
...
Data Reading (1. / Software)
|
|
V
Confirmation (2. / Software)
Dialog Window
Preparation
|
|
V
Manual (3. / User)
Data Confirmation
|
|
V
Further (4. / Software)
Data Processing
...
Please note that there are many kinds of diagrams that can describe the same behavior, but it is better to use pen and paper instead of wasting time playing with sophisticated tools. These tools are more suitable for other tasks.
You read the design documentation, take another sheet of paper, and draw the new version of the same process.
...
Data Reading (1. / Software)
|
|
V
Internal (1.a / Software)
Data Correction
|
|
V
Confirmation (2. / Software)
Dialog Window
Preparation
|
|
V
Manual (3. / User)
Data Confirmation
|
|
V
Further (4. / Software)
Data Processing
...
Then you take your diagram and go to the software development department.
Please note, this diagram represents only one of many possible solutions. There are usually several different ways to solve the same problem, and the true engineers discuss them all at the same time in order to choose not the solution they like, but the solution that is optimal for implementation.
Sometimes you downgrade some elements of a perfect solution to make it cheaper. Sometimes you persuade your manager to extend the project budget to get significant quality improvements.
I'll mention here a short explanation from my notes from another project. [ itSotWC::2024-01-16_1, itSotWC::2024-01-16_2 ]
Managers and politicians are one-dimensional beings: "Five is better than three."
Scientists are two-dimensional: "This is not a linear growth. This is an exponent."
The people who have still not lost their common sense are three-dimensional: "Yes. I see your chart of recent economic growth, but my wallet says that you have forgotten about inflation."
Teachers cut off the child's "but"-dimension and flatten his thinking. (The modern education system is today very effective.)
Engineers are forced to routinely perform multidimensional optimizations. They must simultaneously consider many different parameters. A person who cannot hold his grip on many dimensions is not a true engineer.
By the way, we have reached the software development department and found his manager. He says that the new feature will cost 100 man-hours. It is a waste of time to implement it. The German data is rarely read, and a user can get an error message and change numbers manually himself.
You return to your workplace, open the latest version of your software, load some datasets with errors, perform some tests by taking notes, and estimate the average correction time to be about 5 minutes.
Then you take a pen and add this information to your diagram.
...
Data Reading ---. (1. / Software)
| |
\ | / |
\ V / |
Internal | (1.a / Software)
Data Correction | [ SAVED TIME ]
/ | \ | [ + 100 man-hours ]
/ | \ |
V |
Confirmation <--* (2. / Software)
Dialog Window
Preparation ---.
| |
| |
\ | / V
\|/ Manual (2.a / User)
X Data Correction [ WASTED TIME ]
/|\ | [ - 0.1 hours ]
/ | \ |
| |
V |
Manual <--* (3. / User)
Data Confirmation
|
|
V
Further (4. / Software)
Data Processing
...
Then you open a new spreadsheet and write:
| A | B | C | |
| 1 | User time waste: | 0.1 | hours per one manual data correction |
| 2 | Error correction budget: | 100 | man-hours |
Then you look into marketing data and make the following table using 3 conditional formats:
- green background in case the total user time waste is less than the error correction budget, cell "$B$2";
- orange for time waste from 100% to 1000% of the error correction budget;
- red for the time waste above 1000%.
| Number of Users | |||||||
| 10 | 50 | 90 | 130 | 170 | 210 | ||
| Number of Manual Data Corrections per User | 2 | 2 | 10 | 18 | 26 | 34 | 42 |
| 4 | 4 | 20 | 36 | 52 | 68 | 84 | |
| 8 | 8 | 40 | 72 | 104 | 136 | 168 | |
| 16 | 16 | 80 | 144 | 208 | 272 | 336 | |
| 32 | 32 | 160 | 288 | 416 | 544 | 672 | |
| 64 | 64 | 320 | 576 | 832 | 1088 | 1344 | |
| 128 | 128 | 640 | 1152 | 1664 | 2176 | 2688 | |
Then you call your boss and arrange a meeting with the development and marketing departments.
I would say, this is a very optimistic example. Usually, work creeps from green to red much more quickly.
Of course, it is impossible to make such estimations in a real agile project.
First of all, the quality assurance department is replaced with agile testing.
The second problem will be the numbers you will get, if you try to measure the real volumes of work creeping. Even the most optimistic estimations without consideration of full work blocking would be very impressive.
Many years ago, at the times when incompetent people doing a bad job didn't yet know they were excelling in Agile, I was sitting at a conference, and a speaker was telling the audience that software requirements are not needed because they are difficult to define and hard to negotiate.
He was not the preacher of the Agile Age, just its prophet. Modern agile experts would call him a formalist and a retrograde.
We had left the room. A brilliant legal expert who has written some books about software development contracts muttered with a devastated expression on his face, "I don't understand… I don't understand who could agree to such terms… This is a sure loss… Hm… No! I don't understand…"
Vit minus R, 2024, Switzerland
Tags:
- agile,
- economics,
- en,
- it,
- management,
- motivation,
- psychology,
- qa,
- quality,
- re,
- se,
- visualisation
