In the end aren't all designs hard to maintain?

Question

I have looked and thought about good and bad points of my past designs and considering my next venture and what it should be. Everyone says MVC and others say one design doesn't fit all. Frameworks don't help me a whole lot for my projects, mostly because of legacy databases, and my past ideas weren't terribly horrible for the time. One thing I have confirmed. All the design patterns are hard to maintain.

Consider old classic asp and jsp where you mix code and emit html all in one page. Someone says add a column and it's pretty easy to do really. Change the database, add to your SQL statement, add new HTML, almost all right there. If I have a DAL and BLL and UI I have a lot of places to change that. If I have MVC with an ORM, lots of places. So for a minor change that design wasn't bad. Classic got bad when there are lots of changes to make and I have lots of changes.

When webforms came along I got to separate more with things but changing things still took work, just at separate levels. I never have had a "designer" so sending the UI web page to a designer like all the books said without ever having to send the logic never really made a big deal to me. I'm sure it did to someone. Anyway, I accepted it as "correct" because Microsoft said so.

Then everyone inside MS decided to push MVC and I found out that MS didn't invent MVC, separation of layers, and so on. MVC seems to be very good but not easy. Each change means changes on all kinds of layers.

In the end all the design patterns, MVC, no-design, DAL, no DAL, BLL, etc. hard to use and maintain. Nothing is easy. It's hard work. I wish I could see the grand design in it all but I see hardship in all of it. "Easy to maintain" is a relative term it seems.

In the end aren't all designs hard to maintain?

Answer 1

It is possible to design a project with long-term maintenance in mind. The best advice I have heard is to encapsulate change * . If you design your code so that the most commonly modified parts are the easiest to change, your maintenance headaches will be reduced.

Of course, there is always the possibility (almost a certainty, with long-lasting products) that something you haven't considered will have to be changed.

In that regard, any worthwhile project, product or process will become more and more difficult to maintain as time goes on. Nothing lasts forever!

* From Bruce Eckel's "Thinking In ..." series of books.

Answer 2

The problem with all designs is that you are making them for the state-of-the-art use cases + some use cases that you think might occur in the future. My experience shows that the new features that are requested were almost never thought of before and the system has to be touched deeply, whatever design is used.

One of the few things that make deep changes easier is the DRY (Don't Repeat Yourself) principle. If you are changing something, it's a big help if you have to change it only once. Design patterns should help to avoid repeating yourself and thus they are often preferred over the "mishmash" methods.

However, if you write the mix code in a way that you do not repeat yourself and make it readable, its maintenance costs can be equal or superior to the maintenance costs of a MVC application.

Answer 3

Consider old classic asp and jsp where you mix code and emit html all in one page. Someone says add a column and it's pretty easy to do really.

I disagree with this. I was given this exact request and after struggling with it for a few hours, I settled on just adding the new info to an existing column. The problem was that certain columns were shown and hidden depending on conditions, and the contents of each changed too. Instead of saying Table.Columns["price"].Visible = false;, I would have had to reverse engineer the spaghetti code of nested ifs to insert a column that lined up with its header. Obviously it's possible to write cleaner classic ASP, but abstraction is a tool that can be used for good or evil, as with anything else.