1. Happier Users
With plugins, users are not limited to the functionality built into the base product. They can enhance the product/customize it to their needs by installing third-party plugins. This is the obvious reason. In fact, many people think this is the only reason.
2. Happier Developers(!)
Plugin-based programs are usually very easy to debug. Let me tell you how a typical debugging cycle works in such programs: You start (as always) by writing a test that captures the bug. Then you gradually remove plugins from the program until you arrive at the minimal program that still produces the bug. If you do it via a binary-search (over the set of plugins) the process will converges quite quickly.
Usually, you end up with a very short list of plugins. A few educated guesses will help you spot the bad plugin right away. Even if you're out of guesses, you're still in a very good position: the amount of code that needs to be scanned has been dramatically reduced.
Compare that to a program that is not plugin based. Such a program cannot function without any of its parts. Thus, you have no systematic way to reduce the amount of code involved with a bug.
3. Plugins are Agile
Breaking up a user request (story or even theme/epic) into tasks is usually a breeze in a plugin-based program. One should simply break the story functionality-wise and implement each piece as a separate plugin. This is much easier than breaking a story according to implementation-oriented tasks. Bottom line: less overhead due to iteration planning.
4. Easy Collaboration
A real story: A few months ago my team was asked to assist another team with their product. That product had plugin support so we simply implemented our additions as plugins. We were not afraid to break things because we had no access to the source code of the core (big plus). Also, the core was written in C++ but the plugin system is in Java (second big plus).
That's my top four reasons. As you can see only the first point is user-oriented. The other three points are all developer-oriented. Surprising, isn't it?
Point #2 is moot because plugins are just a dynamically deployable components against a standardized interface. A well componentized application (i. e. with clear interfaces) is just as easily "debugabble" because the different components will be unit tested and can thus be individually "debugged", without having to remove components one by one to see what is wrong.
You also neglect the effort that has to go into determining the right plugin configuration (including the right versions), downloading them, configuring each one in just the right way in order to reproduce the bug. This can be a nightmare.
jakob
August 28, 2009 at 10:51 AM@Jakob
"the different components will be unit tested and can thus be individually debugged"
What data will you feed into such an individual component when you try to debug it?
Working on a bug starts from some initial input that is known to produce the bug when fed into the top-level component. If all you have is highly decoupled components you need to break this input into small pieces - that correspond to the inputs that individual components will get when the top-level component processes the initial input. Then you need to compute the expected output for each such input. This is a manual process which is tedious and highly error prone.
"You also neglect the effort..."
Like most things design choices, plugin support has its tradeoffs. I am not saying that one should always employ plugin-based designs. I am, however, surfacing some non-obvious reasons in favor of such designs.
Unknown
August 28, 2009 at 11:59 AMAgree with previous comment. Plugin architecture allows you to identify almost instantly the piece of code with problems. If you have to ask somebody to eliminate suspects than you are already in the middle of the hell.
On the other hand you have another advantage which should be at top. It allows a company to build many products using same platform. Reusing modules provides two awesome things: good communication and standards.
My personal belief is that plugin architecture value resides in the culture it produces.
padreati
August 28, 2009 at 12:07 PM>>What data will you feed into such an individual component when you try to debug it?<<
What data (e. g. configuration settings) will you feed your plugins? What data will you feed your application? I don't understand the point of this question. If I have unit tests, I know how to feed my components with data, it just has to be the data that reproduces the bug. This can be difficult whether you have a plugin architecture or not.
@padreati
>>It allows a company to build many products using same platform<<
This is also true for regular componentization. You guys are confusing plugin architecture with components. A plugin architecture means nothing else than that your components can come from third parties now. Period.
jakob
August 28, 2009 at 2:37 PM@jakob
Here's an example (Javascript), to illustrate the point:
function isZero(n) { return n == 0; }
function sum(a, b) {
return a != 8 ? a + b : b; }
function fib(n) {
if(isZero(n)) return 0;
if(isZero(n-1)) return 1;
return sum(fib(n-1), fib(n-2));
}
What we have here is a Fibonacci function, fib(), implemented on top of two other functions: isZero(), sum(). For the purposes of this discussion assume each function is component with a clear interface and a whole set of unit tests.
Clearly, this implementation is buggy. sum() does not work correctly when a == 8. However, a bug reported by user will just tell you that "f(9) returns 18 where the correct result is 34".
This does not help you in pin-pointing the bug as the problem can be either in sum() or in isZero() or maybe in fib() itself.
In order to decide that the problem is in sum
() you need to trace the execution. You will have to go through numerous calls to sum() before you realize that sum(8,5) returns 5. Also, it is just as likely that you start tracing the calls to isZero() before you decide to turn your attention to sum().
This is the process of breaking up the initial input into component specific inputs. It usually entails long debugging sessions and a considerable mental effort.
Unknown
August 28, 2009 at 3:40 PM