Down with the quality!
If we roughly consider the quality of time between failures, it is clear that the budgets for different criteria are different. As in IT, and in normal production.
If the pan can break in six months, you can take cheap steel, simple coating and Chinese workers. If you need a ten-year lifespan, you will have to take good materials, expensive technologies and made in Germany.
If we can ignore that one user in a thousand falls off the site, we can quickly bungle something simple. If the loss of one financial transaction threatens with a fine of half a million, you will have to think through the architecture in detail, choose reliable libraries and be serious about testing.
')
But at the same time “quickly and simply” does not mean “bad”.
If the site is made in such a way that every tenth one falls off of it, then we will have a headache, constant emergency payouts and a bottomless hole where the budget falls. And to brag about how much money saved on quick and easy development and the absence of analysis will not work either.
And here I want to remind for some reason the moment forgotten by everyone.
Avraly, expenses and headache, we have only when the system is closed. If it is open, all these joys will be given to someone else.
We didn’t spend the money on not to spawn bugs, and the cost of dealing with errors is borne by someone else.
The user catches the data, fills in Excel and corrects pens. But this is his time and his problems.
The customer suffers losses due to defective components and opens the testing department, slamming dozens of people for a year to prevent us from having invested one man-month. But this is our money, and that is it.
And, of course, we don’t care how much time and effort the anonymous distant visitors of our wonderful website spend, trying to overcome our bugs, or, all the more, users of our wonderful free libraries, who are struggling with unpredictable errors and general curvature of architecture.
We sit at the origins of the food chain devouring time and resources of bugs, and we do not care at all that we are releasing into the big world.
If the pan can break in six months, you can take cheap steel, simple coating and Chinese workers. If you need a ten-year lifespan, you will have to take good materials, expensive technologies and made in Germany.
If we can ignore that one user in a thousand falls off the site, we can quickly bungle something simple. If the loss of one financial transaction threatens with a fine of half a million, you will have to think through the architecture in detail, choose reliable libraries and be serious about testing.
')
But at the same time “quickly and simply” does not mean “bad”.
If the site is made in such a way that every tenth one falls off of it, then we will have a headache, constant emergency payouts and a bottomless hole where the budget falls. And to brag about how much money saved on quick and easy development and the absence of analysis will not work either.
And here I want to remind for some reason the moment forgotten by everyone.
Avraly, expenses and headache, we have only when the system is closed. If it is open, all these joys will be given to someone else.
We didn’t spend the money on not to spawn bugs, and the cost of dealing with errors is borne by someone else.
The user catches the data, fills in Excel and corrects pens. But this is his time and his problems.
The customer suffers losses due to defective components and opens the testing department, slamming dozens of people for a year to prevent us from having invested one man-month. But this is our money, and that is it.
And, of course, we don’t care how much time and effort the anonymous distant visitors of our wonderful website spend, trying to overcome our bugs, or, all the more, users of our wonderful free libraries, who are struggling with unpredictable errors and general curvature of architecture.
We sit at the origins of the food chain devouring time and resources of bugs, and we do not care at all that we are releasing into the big world.
Source: https://habr.com/ru/post/184082/
All Articles