Any road worth walking is endless. :-)

I agree that automated test and all the things I have preached at your previous place of employer can help improve maintainability if used well. And I think you’re right that it can be sold, too.

On a further note, like most interesting characteristics, it is impossible to measure maintainability without putting a system into production and improving it incrementally. So incremental deliveries might be a good tool for selling techniques for maintainability.

As Robert Glass says (in Facts and Fallacies about Software Development): The maintainance period is not the problem, it is the solution.

Automated tests improve maintainability, so if customers start demanding that, then one piece is in place. For this part, we also have good measures.

I think customers are willing to pay for it if they understand that it is good economy. The customer will probably need to hire people to check for them, just like they often hire people to check the architecture, the project management and more.

Are we able to reliably deliver it? I don’t know. Are we able to reliably deliver good architecture? There are at least some best practices one can state (like the negation of these tips: http://thc.org/root/phun/unmaintain.html).

Even though it is difficult to standardize tests for this, one can try to make some changes and see how difficult it is. If it is hard, you will see what makes it hard, and hopefully whether it really needs to be like that.

Are you being defeatist? I agree that the road is really long, but I don’t think it is endless.

Do you?

Any road worth walking is endless. :-)

I agree that automated test and all the things I have preached at your previous place of employer can help improve maintainability if used well. And I think you're right that it can be sold, too.

On a further note, like most interesting characteristics, it is impossible to measure maintainability without putting a system into production and improving it incrementally. So incremental deliveries might be a good tool for selling techniques for maintainability.

As Robert Glass says (in Facts and Fallacies about Software Development): The maintainance period is not the problem, it is the solution.

Automated tests improve maintainability, so if customers start demanding that, then one piece is in place. For this part, we also have good measures.

I think customers are willing to pay for it if they understand that it is good economy. The customer will probably need to hire people to check for them, just like they often hire people to check the architecture, the project management and more.

Are we able to reliably deliver it? I don't know. Are we able to reliably deliver good architecture? There are at least some best practices one can state (like the negation of these tips: http://thc.org/root/phun/unmaintain.html).

Even though it is difficult to standardize tests for this, one can try to make some changes and see how difficult it is. If it is hard, you will see what makes it hard, and hopefully whether it really needs to be like that.

Are you being defeatist? I agree that the road is really long, but I don't think it is endless.

Do you?

My main point, however, is this:
the customer must demand and control that the system they buy is reasonably maintainable. Nobody else will do it.

It is true that nobody else will do demand maintainability. But is the customer inclined and informed enough to do it? Willing to pay for it?

And if the customer is willing to pay for it, are we able to reliably deliver it?

And a last question: Am I being defeatist?

My main point, however, is this:
the customer must demand and control that the system they buy is reasonably maintainable. Nobody else will do it.

It is true that nobody else will do demand maintainability. But is the customer inclined and informed enough to do it? Willing to pay for it?

And if the customer is willing to pay for it, are we able to reliably deliver it?

And a last question: Am I being defeatist?

The company creating the software, however, usually doesn’t have much interest in this, because they will mostly get paid in full for any job they do after delivery, and the maintainability of their creation does not effect their chances of getting a contract for the maintenance.

So the only victim here is the customer, who will have to pay more for changes (well, and the poor people who are assigned to the maintenance job, and they are quite often not those who developed it).

The second problem is the quantification of maintainability. That is not easy to do, but we all clearly see the difference between code that is easy to change, and code that we don’t dear to touch. This tells me that it should be possible to test this somehow.

My main point, however, is this:
the customer must demand and control that the system they buy is reasonably maintainable. Nobody else will do it.

The company creating the software, however, usually doesn't have much interest in this, because they will mostly get paid in full for any job they do after delivery, and the maintainability of their creation does not effect their chances of getting a contract for the maintenance.

So the only victim here is the customer, who will have to pay more for changes (well, and the poor people who are assigned to the maintenance job, and they are quite often not those who developed it).

The second problem is the quantification of maintainability. That is not easy to do, but we all clearly see the difference between code that is easy to change, and code that we don't dear to touch. This tells me that it should be possible to test this somehow.

My main point, however, is this:
the customer must demand and control that the system they buy is reasonably maintainable. Nobody else will do it.