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. :-)

> 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.