Evidence of Bad Design: Updating feature A breaks/interferes with existing feature B

Question

I am working on a Javascript Web App & I am finding as I expand the program & add new features(new animations) it causes existing features to break or work differently than prior to adding that new feature. So as I continue to finish the app, it keeps breaking old features & I have to go back & redo/update those features. So it seems I never complete a feature because I am always coming back to it so I can get it to work nicely with other features.

Is this indicative of bad application design? Or is this a normal feature of computer programming, ie just like how in any program you will spend 20% of time developing the program & 80% of the time fixing bugs(or is it maintaining the program?)?

Are there design &/or any other techniques I can employ to avoid having this problem occur?

The application is a renderer (which takes an XML file which contains information about objects that perform animations - move around, fade etc.) that creates HTML elements & animates them.

The design is OOP, with as close as you can get to classes in Javascript by using prototype. It employs ALOT of multiple inheritence. It also makes use of the anonymous functions where possible so I think it would be very much like a Java project because they both have OOP, anon functions & inheritence. There is a class purely dedicated towards animation called AnimatedObject & many objects inherit from this class. You just perform an animation by simply calling a function from that class such as myAnimObj.performFade() or myAnimObj.performRotate().

Answer 1

You don't need to avoid your current situation to feel better. Just name it: Refactoring.

The process of introducing new feature A that needs changes in existing feature B is:

1. change B so that it still works as expected and allows future A to be inserted
2. insert A with updated B
3. test B
4. test A

As you see, you need to have a good regression test suite.

Answer 2

spend 20% of time developing the program & 80% of the time fixing bugs

No, definitely this is not normal: it's a sign the project has reached and (far) passed the point of reasonable maintainability. I'd consider even 50/50 to be a bad sign.

Formally speaking, if by modifying feature A you break feature B, it means you don't understand the code. If you did understand it, you wouldn't leave undesired side effects by making changes in it.

However, who's to take the blame for this? Is it the code that's too messy, complex to be understood in its entirety, or is it you unwilling or unable to understand the code? That's an important question to be answered before you either sit down and study the code or persuade your management the code requires a fundamental rewrite.

In general, number one contributor to complexity of the code (not functionality) is too many static variables or class fields. A program or an object has a finite number of states, which comprises of all possible combinations of values in variables. With each new variable you get an exponential growth of the number of possible states, i.e. you get a growth of complexity and incomprehensibility for a human mind.

Good design minimizes the number of possible static states and isolates components as much as possible. Look at the code from this point of view, and see if you can understand and memorize the meaning of each static var/member field and each function. If you can't recall something the following day, I'd say go for refactoring.

Answer 3

From what you describe, it seems that old code depends on more recent code.

Normally, recent, less stable components, should depend on older, more stable components, not vice versa.

Check your design and make sure the latter does not occur.

An easy technique is to draw a diagram and visualize the dependencies with arrows. If you notice that a stable component depends on an unstable one, consider applying techniques like dependency inversion.

Answer 4

Are there design &/or any other techniques I can employ to avoid having this problem occur?

When you say that updating feature A breaks/interferes with existing feature B, it sounds like the code is written non-orthogonaly. Generally you want to have youre code written orthogonally (see this question for good reasons for why).