6

Is there any data on which paradigms allow for code which is easier/cheaper to maintain? Certainly, independantly of the chosen paradigm, good design is cheaper to maintain than bad, but there should probably be major differences coming only from the paradigm choice.

Unstructured programming, for instance, generates very messy code (spaghetti code) which is expensive to maintain.

In object oriented programming, implementation details are hidden and thus it should be pretty cheap to change those.

In functional programming, there are no side effects, thus there is lesser risk of introducing bugs during maintainance, which should be cheaper.

Is there any data on which paradigms are the most cost-efficient when coming down to maintenance? If no such data exists, what is your take on the question?

3 Answers 3

3

Human beings can only manage so much complexity at a given time.

You want a paradigm that either reduces or hides the complexity away for you.

  • Lower complexity means more maintainability.
  • Lower complexity means less communication effort.

The best paradigms in terms of maintainability are those that:

  • hide away the complexity so you don't have to have it in your face all the time.
  • allows you to add functionality without modifying existing ones.

IMHO I would go with a mixture of the following:

  • layered architecture ( not necessarily n-tier, just don't mix business logic with presentation logic ).
  • use OOP in the bussiness logic. I know encapsulation and code reuse can be achieved using non-OOP, but with OOP you have well documented patterns. You can stand on the shoulders of giants.
  • develop an API so programmers build apps based on that API.
  • make the business logic API presentation-agnostic.
  • try the person that developes the business logic layer is not the same one that develops the presentation layer.

I don't know if all these are "paradigms", but I think these approach would be a good balance between cost-efficient maintenance and flexibility.

1
  • 1
    Throwing in my 2 cents: don't forget about using DSLs to help hide/reduce complexity.
    – paul
    Nov 19, 2012 at 18:05
0

I'm not aware of any data that exists, but I'm just getting into the field so I'm just now seeing studies, etc., but I've also taken a look at a variety of programming methodologies, so it interests me a lot, and here's my take on it:

Any sensible paradigm, done right, will give you good maintenance results. Unstructured programming is not sensible.

The biggest problem is not really your paradigm (whether that's programming or development) that introduces a lot of cost, it's the code smells. You have a lot of low-hanging fruit there, whether that's renaming variables, shortening functions, etc., that will provide a much greater return on maintenance than picking a different methodology.

2
  • I'd called thoughts like 'Any sensible paradigm, done right, will give you good maintenance results.' as unstructured thinking. What about quasi-unstructured programming ? Is it good or not?
    – alehro
    Nov 16, 2012 at 18:28
  • You mean segments of unstructured programming scattered throughout your code? My young experience (having now 1.5 years of professional programming under my belt) echoes what I wrote. Any amount of deviation from <insert sensible paradigm here> will cause horrible maintenance issues. When I look back at my own code, I can tell you where I deviated because I really have to think and figure out why the heck I did something. When you have and adhere to good standards, code comprehension is as easy as it possibly can be. Nov 17, 2012 at 12:39
0

From this paper, it appears functional programming and object oriented programming offer good readability and maintainable code. Imperative programming scores low on maintainability as it becomes difficult to reuse sections of large programs. Structured programming suffers from low maintainability by being hard to make revisions once the program is written.

FWIW, from my experience, I have hated working on programs that have been written with a rigid, top-down approach. Especially so when the original developers were not around.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.