There are several sources of spaghetti code that are possible:
A complex domain, as you mention, where a complex entangled mess is the most elegant possible solution.
Resource constraints and temporal tradeoffs. Re-architecting the system after adding each additional functionality is too time expensive, even when a new architecture could simplify the overly complex design. Social forces like “the market” or “grant money” mean it makes more sense to build the feature in the poorly architected way.
Performance optimizations. If you code needs to fit inside a 64kb ROM, you may be very limited in your ability to structure your code cleanly.
Lack of requisite skill. A person may not be able to provide a simple design even though one exists, even given infinite time.
If I had to guess, number 2 is the largest source of spaghetti code that Less Wrong readers are likely to encounter. Number 4 may be account for the largest volume of spaghetti code worldwide, because of the incredible amounts of line-of-business code churned out by major outsourcing companies. But even that is a reflection of economic realities. Therefore, one could say that spaghetti code is primarily an economic problem.
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.
There are several sources of spaghetti code that are possible:
A complex domain, as you mention, where a complex entangled mess is the most elegant possible solution.
Resource constraints and temporal tradeoffs. Re-architecting the system after adding each additional functionality is too time expensive, even when a new architecture could simplify the overly complex design. Social forces like “the market” or “grant money” mean it makes more sense to build the feature in the poorly architected way.
Performance optimizations. If you code needs to fit inside a 64kb ROM, you may be very limited in your ability to structure your code cleanly.
Lack of requisite skill. A person may not be able to provide a simple design even though one exists, even given infinite time.
If I had to guess, number 2 is the largest source of spaghetti code that Less Wrong readers are likely to encounter. Number 4 may be account for the largest volume of spaghetti code worldwide, because of the incredible amounts of line-of-business code churned out by major outsourcing companies. But even that is a reflection of economic realities. Therefore, one could say that spaghetti code is primarily an economic problem.
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.