The Safenet and Reusability

When I am designing a software product, I would like to identify the risk levels of the components. The risk levels will be considered both from the characteristics of the technologies the components are using, and from the customers' point of view. For example, I would identify the risk of ActiveMQ broker as high, and database connection as medium or high.

There are two reasons to do that.

First of all, but identifying the risk level of the components, you will put different components in different places and treat them differently. For example, you don't want to build an ActiveMQ embedded broker into you Central Controller System, because your customer won't effort to crash the Central Controller, or they don't even want to restart it.

Secondary, and this is my favorite, you want to build some safe net for those high risk components, and make sure when bad things happen, your customers won't freak out. They don't have to know most of the case. This is my 80/20 principle: in most of the case, you can't handle all situations, building safe net will save you much precious time to focus on the business you need to focus on.

However, not everyone understand this is the life-saving trick.

Today I heard about a related story. In their product, there is a safe net was designed to monitor and restart the JMS broker. This safe net tool was built depending on several other home-made, unreliable components, and a list of unnecessary business logic. I heard that that reason to do that is to make sure the reusability. Finally, a defect comes along.

I don't really care about the defect. The problem is not about the defect, but the way we should build a safe net solution.

Please look at this. What do we want reusability? Software reusability is very important. We don't want to duplicated our code every where, making similar logic all over again and again. By doing this, we can easily improve our system by changing few places. It is good for debugging, system evolution, and even change design.

However, the goal of reusability is to make development easier and the software better, not harder. Sometimes, I saw people try to make things reusable just for reusability. not anything else. In this way, they make the system much more complex than it should have been. A lot of unnecessary logic dependencies are put onto the system.

It is very difficult to argue this. One thing I would suggest the engineers to look at is coupling. When you are building one thing, how many other things you need to worry about? However, this is also arguable.

But for the safe net solution, you must need to guarantee it work straightforwardly. This is the way you survive the system, don't put any more risks onto it.

For other parts of the system, I would suggest we need to do more book reading and third party software studying. For re-usability, please read the GoF's Design Patterns, look at the good and the bad and truly understand what they are and how to use them. Learnt from successful open-source system, study their architecture and design principles. Don't re-invented the wheel. It is the time of global corporation, we need to learn and grow with the whole world.