Design opinion, configuration inheritance

[naChoZ]

To sum up briefly, I've only crossed over from the syseng discipline to the (perl) developer arena in the last few months. I knew it would be a major transition, but I still find myself getting the wind knocked out of me on occasion.

The specific instance I'm pondering is from my current project. I'm writing what is basically an asset tracker and Nagios configuration engine, with a user friendly interface all in one. We were discussing the topic of inheriting from nagios "template" service definitions¹.

My thought was that, with the exception of creating circular inheritance, when a user creates a new template they should be allowed to inherit from basically any available template (keeping in mind that certain template types are only usable by certain device types). Nagios behaves this way, so I thought this application should probably behave this way also. After lengthy discussion both ways, I was finally met with "Because it's bad design." As the department newbie, I didn't even need to use the force to sense that it was time to stfu.

The other folks in my dept are of the opinion that it should be very specific, a top level master template, a command based template (i.e. "template_snmp_check"), a device based template (i.e. "template_snmp_check_Router"), and then, optionally, a custom template from which the actual registered service check definition will inherit configuration options.

I was wondering about the opinions of the other developers here. Is it good design to limit an application like this, which will control another application, to a rather enforced methodology? Or is it better to go with "Since Nagios can do it, this app should do it...?"

And also, has anyone else switched disciplines and experienced their own difficulties with the change?

¹ (Quick Nagios explanation. Every item on every device you want to monitor in Nagios, disk space, cpu, router interfaces, running processes, etc, requires a service definition in the configuration. You don't have to create an entirely new service definition with every single configuration option every time, though. You can tell it a service name to use to inherit options, a parent template. Services can inherit from each other and have all sorts of parents, grandparents, gggggrandparents, etc.)

[dragonchild]

My first impression is that your entire developer team is mis-using OO. Nagios doesn't have classes - it has parameters. There are no behaviors associated with that data, other than getters and setters. So, maybe you should have a single class that actually composes the data structure (presumably a hash) from other data structures.

As for general design ideas ... it's usually better to start with more specific and generalize later. There are several reasons for this:

• You usually will not have enough understanding of the problemspace until you try it a few times
• You may never need all the generalization, so why waste time building it?
• It's better to have something running now, even if it's not perfect, than to have something perfect that doesn't run until later. You can always improve it later, if you need to.

[revdiablo]

It's better to have something running now, even if it's not perfect, than to have something perfect that doesn't run until later. You can always improve it later, if you need to. [Emphasis mine]

I can't agree more strongly. It is not any good writing code without having the ability (fortitude? strength of will? maybe some other words fit here too) to change it later. Code (and its design) is fluid, and dynamic. Trying to set it in stone on the first try is surely going to cause problems later.

I think many people are afraid to make major changes to their underlying code, though. They fear causing new bugs. This is a legitimate fear, and definitely should be considered. My favorite way to decrease the fear is by having a good test suite. Having that safety net there to make sure the API is followed according to docs -- even when there are major changes made underneath -- is a very reassuring thing.

Of course, a bad test suite might give a false sense of security, but that's another post altogether. :-)

[naChoZ]

> My first impression is that your entire
> developer team is mis-using OO. Nagios
> doesn't have classes - it has parameters.
> There are no behaviors associated with
> that data, other than getters and
> setters. So, maybe you should have a
> single class that actually composes the
> data structure (presumably a hash) from
> other data structures.


I'm greatly simplifying what it's all about. There's actually quite a bit more to it. It's more of an API, really.

They have their own homegrown set of web apps here that all use the same basic framework and I'm building the asset manager/nagios interface into that. I've modeled it a little bit like RT.

I'm not entirely certain how you define 'behaviors' in this context, but it's definitely more than just getters and setters.

[tilly]

I'm very suspicious when someone says "because it is bad design" and then doesn't follow that up with specifics on why it is a bad design. (Is it a bad user design? A bad programming design? Is the person that you're talking to worried about being confused by the flexibility? Worried about users making a mess of things? Worried that users will be confused? Will it force you to write a lot of very generic code when you could write something simple?) If I know how the other person thinks it is bad, then I can form my own impression of whether I agree. (Sometimes you have to live with decisions that you disagree with.) Eventually my trained impressions may become useful opinions.

Depending on specifics that you haven't given us, I could wind up choosing either design. I personally like providing a more generic design with the hope that I can get people to solve their own problems using the flexibility. That isn't always workable in the real world. I enumerated a few of the possible reasons above in my list of reasons that someone might think that a bad design.

[naChoZ]

> I'm very suspicious when someone says "because it is bad
> design" and then doesn't follow that up with specifics on
> why it is a bad design. (Is it a bad user design? A bad
> programming design? Is the person that you're talking to
> worried about being confused by the flexibility? Worried
> about users making a mess of things? Worried that users
> will be confused? Will it force you to write a lot of very
> generic code when you could write something simple?) If I
> know how the other person thinks it is bad, then I can
> form my own impression of whether I agree. (Sometimes you
> have to live with decisions that you disagree with.)
> Eventually my trained impressions may become useful
> opinions.


Yes, I get suspicious myself, which was one of the reasons I thought I'd get some opinion here. As to your questions, I'd say the last two apply, confusion from the flexibility and user's making a mess of things. (Especially the latter. You should get a load of the current setup.)

[perrin]

It is a good idea to do the simplest thing you can get away with, so if making it more specific is simpler, and will thus lead to fewer bugs and less user confusion, you should do it.

[Anonymous Monk]

Is it good design to limit an application like this, which will control another application, to a rather enforced methodology?

I don't know. The reason I don't know is that I don't know what the ultimate design goal of the project is - and who should be using the templates (and for what goal). What is going to be more important, doing the simple things, or the hard things? Sometimes it's worthwhile that hard things are more difficult to do, in order to keep simple things simple. Sometimes it's ok to make simple things a little harder so that hard things aren't too difficult.

Who's going to the user of your template system, and what is (s)he supposed to be doing with it? That should be the most important question when designing your system.