Strides Interactive

Cascading Chain EffectFiled Under: Weekly Tuesday Dose of goodness

Hi all,

This week I’m going to talk about this effect known as Cascading Chain Effect. One can take an analogy from a database system; this effect known as Cascading Deletion or Drop. That means, the deletion of a certain item, record or table in the database will automatically result in the deletion of other objects.

But Cascading Chain Effect is not exactly Cascading Deletion.

So what is it exactly? Read on…

Introduction

First of all, Cascading Chain Effect has several characteristics. One of the obvious is of course, the cascading effect which affects one or more objects.

A more serious variant of this effect is known as Cascading Fan Effect.

When we’re talking about a chain, it simply meant a single path or line of objects that are affected by the root cause. As for the Fan variant, think of it as an inverted tree; the root cause of the problem causes several objects that are directly involved to reflect a problem.

These several objects then scatter and split into many many other paths which looks exactly like a fan. (ie, Sea Fan).

You’ll probably hear one of the familiar words in this post - Regression.

Root Cause

The root cause of cascading chain effect lies in the root cause of the problem as well. We all know, in software development, when you see a “bug” occurring on the screen, if it’s visible, chances are, it’s not a bug but a symptom.

Therefore we’ll conduct our due investigations and realised that it’s not just a single point that caused a problem. It’s a long chain of events that led up to the problem.

So what’s next? We have to rush to fix and ship. So how?

Well.. let’s just patch it. Hack it! Fix it!

Yes, it works! It resolved the initial problem and it no longer appears on the screen. Yay! Job well-done! We can all go home on time!

So you think!

Resolving a symptom without a systematic approach is almost a sure path to disaster. It’ll almost certainly break other codes that might be working correctly in the first place. Otherwise known as regression errors.

This is therefore, the effects of a cascading chain. Once the chain is broken, depending on the length of the chain, it’ll take as long to fix the problems caused by the chain effect. The problem is, this chain is usually hidden from us even if we’re the architects of the software.

Detection

So, how can we detect the weakest link in the chain?

Well, the solution is usually manual and requires some careful thought processes in order to succeed. The solution involves in reviewing the design.

The design is split into 2 areas. Business Design and Technical Design.

Both designs must be reviewed in order to identify design flaws or requirements mismatch. The following questions can then be asked:

1) Is there a need to have to many dependencies?
2) Are we 100% sure of what we’re using? ie, 3rd party libraries, 3rd party engines, etc. Did we use it wrongly?
3) Is the technical design well-balanced enough to reduce coupling?
4) Are the technical requirements translated and mapped correctly? Good programmers can sometimes be lousy translators, reducing their worth and credibility.
5) Is there a flow chart (or UML tools) that clearly describes the flow of the application?

These are just a few of the many possible questions that can help identify possible chain problems.

Prevention

There’s no 100% prevention to cascading chain effect problems. These problems are part and parcel of software development.

Even if you reduce the amount of codes and use scripts like Strides Octopus, it’ll help, but it’ll not eliminate this problem altogether.

Using FOA or SOA does help reduce the chain effect significantly. The reason is because the implementation of the instructions or services are done at method level, which means each of the methods can be designed by choice, to be as atomic and independent as possible.

This makes it easier to highlight crashes, problems or bugs since they’re all “registered”.

Software testing tools can also help prevent this effect from occurring as well. Tools that can help prevent regression errors occurring on the method level, allowing the slightest deficiencies to be captured as early as within a day. Regression error prevention is one of the bigger bets that will help prevent a cascading chain effect from happening.

Advanced tools can even assert the state of the entire class, making it as foolproof as the business design mandates.

Cascading Fan Nightmares

One of the worst things that can happen is when one of the code isn’t working properly and the rest of the developers knew it but does nothing to remedy the situation.

This is however, very true when 3rd party libraries are used. We all know, whether it’s 1st party, 2nd party or 3rd party, we ALL ARE JUST HUMANS. We make mistakes no matter how good our processes are. These mistakes can be made in several perspectives.

The libraries can for all we know, be 100% perfect technically. But if there’s a lack of proper documentation or clear explanations, people can still make mistakes with it. This is just one example.

Since we do not have much domain knowledge in terms of the code and flow with 3rd party libraries, there’s a risk fixing them. Nobody dares to bear that responsibility.

Let’s say, if the management decides to fix them, then they risk having their fix overwritten by a newer version in the future unless they report the bug and submit their fixes as well to the original authors. (assuming that it’s an open source 3rd party library)

In most cases, developers will just observe the fault and try to work around it.

This is when a chain turns into a fan.

We know that when we wrap around a 3rd party library, there’ll be a lot of other programmers that call these wrapper classes.

If the wrapper classes are written to work around the fault discovered earlier, what’s going to happen? For now, it may look fine and dandy. But as soon as a new version of the 3rd party library is released and the management decides to upgrade it. If the new version fixes the fault, then the entire development team is headed towards disaster! A complete nightmare awaits them.

Soon they’ll trace the symptoms of all their problems back to the wrapper classes and then realised that the wrapper was built on top of a mistake.

For example, if I pass 1 and 1 into the method - int ThirdPartyMath::add(int a, int b) and I get 3.
If I pass in 2 and 2 and get 5
If I pass in 3 and 3 and get 7

Then in my wrapper, I’ll simply do this:

int Wrapper::add(int a, int b)
{
return ThirdParty::add(a, b) - 1;
}

Get the idea now?

Conclusion

In conclusion, I do not discourage the use of 3rd party libraries as long as the developers know what they’re doing or using.

Cascading Chain or Fan Effect is common in software development due to its natural tendency to have dependencies on each other.

Do not build mistakes on top of mistakes. If you must, document your workaround clearly and make it known to everyone that use your classes.

Justify the use of 3rd party libraries; don’t use it just because it can give you some feature that you’re lazy to implement it yourself. Don’t use “don’t reinvent the wheel” as your lame excuse for not doing the right work.

Use software testing tools to determine the predictable state changes of your classes! Do not underestimate the power of white box unit testing.

All in all, it has been a rather accident-filled week for me. Therefore, I’m just going to end it here and take a short mental break till next week. Yeah, I’ll still rant next week.

Signing off,
Jeremy