Plugin Architecture: Reversed Effort

Are you considering plug-ins in your next application/tool?

Plug-in architecture is not a new concept, probably as you know it comes from a long time, and there are a bundle of stable “solutions” to support that, such as “Eclipse/OSGi” and others. Indeed there are several good technical arguments that can catch the development team’s eyes when they decide to adopt this kind of solution, taking into account what they are planning for their application. For example:

• How can a functionality be added in a future moment?
• How can the functionality be increased after delivering?
• How can activated a component at runtime, following a specific component/plug-in lifecycle?

There are some strategies/patterns/definitions behind the scenes when the talk is plug-in architecture. I really encourage you delve into this subject.

On the other hand, nowadays we can see interesting points from a business perspective , when a team decide to develop an application/tool on top of a plug-in architecture. It is fact that the market has been accepting these new applications/tool in a good way, not “just” because there are relevant good technical arguments (but again, it depends of what you are planing to develop in terms of application/tool), but because there are different benefits that can be seen through the business perspective.

Usually the business team can take advantage of the ecosystem created around of a plug-in architecture, and define a business model to support the application on the market, involving your costumers and patterns throughout a profit relationship. It is possible to do it in an easy way, because one possibility is introduced naturally:

• The application can just create a “contract”, defining a functionality/opening that it does not provide itself, although must be added by plug-ins.

This interesting possibility opens the doors for actions that aggregate values for the business around the application/tool, even if it is a close or open license. These actions can be represented as:

• The extensibility power, what brings for the costumers and patterns the sensation of “freedom”, where they want to improve/add function as they want, without your interaction.
• The startup of a plug-in market, where third parties will put their mind to think, trying to create some interesting plug-in adding naturally value for your application, what really well worth. Even if they make money without involving yourself, they will be adding value for your business.
• The feedback power, where your application/tool will be all the time being “touched” for others code, and comments/suggestions will popup.

Maybe we can call it as the reversed effort, where your application/tool will be really supported by the third parties, just because you provided a way for them to take part in your business. Of course that there are several others things additional on that, as for example the motivation of your application/tool and etc. But at least the plug-in architecture approach can bring/open more flexibilities and/or opportunities in terms of business, if it fits on your technical stuff.

Where is the boundary between "Rapid" and Quick-and-Dirty on software development?

As you can see, it is a classical Dilbert comic strips, but that probably represent the truth in some spots, specially for those teams that just want to delivery the things, usually as a way to show up productivity. A potential problem here is when the “Quick-and-Dirty” approach becomes the rules and a lack of techniques, process, or even concern, put the “Dirty” as focus, postponing the “Rapid-and-Quality”.

I’m not here to say that “Quick-and-Dirty” is the evil, but I think that there are specifics moments to follow this approach and good ways to “clean” the code and artifacts during the way.

You need to take care, because “Quick-and-Dirty” is a kind of approach that seems to be comfortable(specially for maintenance context with the fast changes around the team), and it can spread through the team easily and sometimes creating a “group think“. It is easy to see as the detrimental to the quality of the software pop-ups just to satisfy the agility on the tasks resolution, and the firsts effects are deficient tests, documentation, control of software life cycle, and the low quality of the code.

If you change the perspective for the software maintenance, it becomes potentiality worst, where in a short time you can see “curatives” scattered throughout the software, without acceptable documentation or even unit tests to guarantee some kind of quality. A very common argument that people adopt to use this approach is: We are agile, We are rapid!. But please, don’t make a mistake, “Agile” in terms of software development approach has not the same meaning as “Quick-and-Dirty”, and even during the software development process if we decide to use some “Quick-and-Dirty” for some specific reason, we need to keep in mind a way to clean it as time goes by.

So, before you decide to dig into this approach or push it on your team, try to understand the potential side effects such as “bug and fix” process, that you will bring into the software environment, try to see if it is just a matter of organization, process or even good sense.