-
Subscribe -
Community
-
Top Commenters
-
Popular Threads
-
Recent Comments
- Thanks for your comment. I've encountered people who talk about non-distributed SOA. I think that is an idea that is totally boring, as it says nothing that hasn't been said for twenty...
- In the text you, like most I think, define services to be distributed. I do not understand why everybody i
- Hi, Eve Thanks for the offer. Let me know if there's any way I can make it easier. Do you think I should consolidate all the articles into one, for example?
- I'd be more than happy to read drafts, run through example code, and whatnot. I've done a little bit of Rails work, but I'm enough of a noob that I'll be able to give good feedback...
- I've never had much luck with the precreated keys. But then again, I use the convention of a null-key to indicate unsaved objects, so I'd run into other problems. FWIW, it sounds like your...
Jump to original thread »
Lately, I have had the rather dubious pleasure of reviewing some of our existing systems and find a plan for improving the maintainability of these systems. I have not done much work like this before, and I came in unprepared for the experience.
Most systems that have been maintained for a num ... Continue reading »
Most systems that have been maintained for a num ... Continue reading »
1 year ago
I very rarely experience that developers take this aspect into account when they produce something. Maybe not so strange though, as it takes a lot more effort and time (and experience and perhaps some talent) than just making it work. As long as you are under some time pressure, and your manager doesn't ask for it (and probably nobody else either), why should you bother?
I think the only way to prevent systems from becoming a mess is to have clear requirements for maintainability, so that it is clear that the system is not finished until these requirements are met.
1 year ago
1 year ago
All requirements should have clear (ideally quantifiable, but probably not always quantified) business value. When the customer is knocking at the door, when the software is getting more and more delayed, how can we value maintainability?
Dark mood today. Sorry.
1 year ago
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.
1 year ago
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?
1 year ago
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?
1 year ago
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.
1 year ago