Thinking inside a bigger box - Latest Comments in On Architecture: The dubious joy of system architecture revision

Re: On Architecture: The dubious joy of system architecture revision

Kukenspeil — Fri, 09 Mar 2007 14:15:25 -0000

Really what you want to do instead of drinking until kl2 is drink util kl3 and then get a kebob. Only then will you be able to deal with the mess of those BBS projects.

Re: On Architecture: The dubious joy of system architecture revision

Johannes Brodwall — Wed, 21 Feb 2007 15:10:36 -0000

Hi, Christian

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.

Re: On Architecture: The dubious joy of system architecture revision

Christian Rørdam — Wed, 21 Feb 2007 14:54:30 -0000

The customers must become aware of their need, and that will probably not happen tomorrow. However, I wouldn't be surprised if a customer signing a contract for a tailor made system tomorrow included some sentences about automated tests. I guess it's a matter of how much attention things get.

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?

Re: On Architecture: The dubious joy of system architecture revision

Johannes Brodwall — Tue, 20 Feb 2007 20:28:48 -0000

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?

Re: On Architecture: The dubious joy of system architecture revision

Christian Rørdam — Tue, 20 Feb 2007 13:22:55 -0000

You are pointing out the two main problems here. I'll respond to the last one first: the customer doesn't ask for it and is in a hurry. However, the customer really needs it, even though they are not aware of this fact. I have seen several reports estimating that "two-thirds of a software system's lifetime cost involves maintenance" (quote taken from http://en.wikipedia.org/wiki/Software_maintenance). So it is really in the interest of the customer that this job is as easy as possible, since it is usually the customer who has to pay for 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.

Re: On Architecture: The dubious joy of system architecture revision

Johannes Brodwall — Mon, 19 Feb 2007 19:29:08 -0000

Personally, I get afraid when I hear the phrase "design for maintainability". I hear that "if we just worked harder, we wouldn't get into these troubles", and "why can't you do it right the first time." Maybe we are in agreement, but I am still looking for some better method than blaming those who've done the best job the could do under the circumstances with the results.

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.

Re: On Architecture: The dubious joy of system architecture revision

Pelle Waagbø Said — Mon, 19 Feb 2007 07:15:03 -0000

I totally agree

Re: On Architecture: The dubious joy of system architecture revision

Christian Rørdam — Mon, 19 Feb 2007 06:29:50 -0000

I'm happy to see that there are people who are concerned about the maintainability of systems. It seems like most people don't care, or they don't have the time right now, or they believe that their code is as easy to understand for other developers as it is for them.

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.