Hey,
I think this is a perspective comparison with the customer.
Mostly the customer does not know 100% what he wants.
So the customer has only a vague idea and the idea has to grow during the development.
In doing so, projects are made "technical debts".
There comes a new function after another.
If there are too many or large debts, they have to be reduced.
Similar to Boolean algebra, you can shorten it to become more efficient. In the process, mature (conceptually mature) functionalities are considered, analyzed and redesigned.
The easy way is to tell the customer from the beginning that debts are made and these are to be reduced in the course. How much debt you have to pay depends very much on the client's mentality / IT affinity and the project.
I find it difficult to use the word "code quality".
The customer ALWAYS gets the best quality that was possible at the time, even if there are debts.
In fact, all my customers understand this and initially prefer a fast development with certain technical debts that are clearly communicated. This clearly shows the customer that the expansion of a function can then be more expensive. You have to pay for debts...
A big technical dept is if you develop something in a technology just because you have knowledge on it but some other technology fits much better for the Project. This gives speed in the first rounds of a project but this may require a complete new implementation in the future. If no debt is allowed, agile working can not be successful.
If you do not pay these debts, you often can not reach the last "20%". But it can turn out in a project that 80% are enough, you pay for something that you do not need (over Engineered)
Creating awareness always helps in software development.
As long as everyone agrees everything is awesome.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey,
I think this is a perspective comparison with the customer.
Mostly the customer does not know 100% what he wants.
So the customer has only a vague idea and the idea has to grow during the development.
In doing so, projects are made "technical debts".
There comes a new function after another.
If there are too many or large debts, they have to be reduced.
Similar to Boolean algebra, you can shorten it to become more efficient. In the process, mature (conceptually mature) functionalities are considered, analyzed and redesigned.
The easy way is to tell the customer from the beginning that debts are made and these are to be reduced in the course. How much debt you have to pay depends very much on the client's mentality / IT affinity and the project.
I find it difficult to use the word "code quality".
The customer ALWAYS gets the best quality that was possible at the time, even if there are debts.
In fact, all my customers understand this and initially prefer a fast development with certain technical debts that are clearly communicated. This clearly shows the customer that the expansion of a function can then be more expensive. You have to pay for debts...
A big technical dept is if you develop something in a technology just because you have knowledge on it but some other technology fits much better for the Project. This gives speed in the first rounds of a project but this may require a complete new implementation in the future. If no debt is allowed, agile working can not be successful.
If you do not pay these debts, you often can not reach the last "20%". But it can turn out in a project that 80% are enough, you pay for something that you do not need (over Engineered)
Creating awareness always helps in software development.
As long as everyone agrees everything is awesome.