I agree with you. I have seen several times how underbudgeted software projects sacrifice general quality due to the reasons you point, and this is later paid in the maintenance phase. I also think that an extreme domain complexity is not the most common cause of the problems. Another source of maintenance difficulties is the laziness when writing the software documentation. A hard-to-read code can be a good code but very difficult to understand by other person when adequate explanations are unavailable.
I agree with you. I have seen several times how underbudgeted software projects sacrifice general quality due to the reasons you point, and this is later paid in the maintenance phase. I also think that an extreme domain complexity is not the most common cause of the problems.
Another source of maintenance difficulties is the laziness when writing the software documentation. A hard-to-read code can be a good code but very difficult to understand by other person when adequate explanations are unavailable.
Perhaps this is a variant of 4⁄2 - lack of documentation writing skill or because ‘it takes time away from writing code’.
Yes, we could say that.