Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Over-designing....or not?

by redlemon (Hermit)
on Jan 10, 2005 at 14:04 UTC ( #420920=perlmeditation: print w/replies, xml ) Need Help??

My current hobby project is an AIM bot that can be used with our service request system to track tickets and request queues. It uses a forking dispatcher that responds to user questions, scheduler and socket events. All actions are plugins that can be added/unloaded and reloaded by the administrators. Fun.

I'm currently tackling the configuration management. There's user data (what timezone, what level of access, which queues, what tickets, etc, etc), queue data, ticket data, etc.

Initially I just used a YAML file I loaded the data from at start and that I wrote to whenever something changed. Then, when the dispatcher became forking, I added file-locking. Then, because the tickets and queues change more frequently than user data, I added more files.

Hmmmm. That's beginning to look like a job for a database.

So I changed to DBD::SQLite2 and Class::DBI::Cacheable. Easy locking, still instant access to data, and very scaleable. But now in stead of simple hash lookups I need to think in RDB terms. There is the overhead of maintaining a database schema. Class::DBI has it's quirks and is not really very small. Same goes for DBI, and DBD

By the way, did I mention I only expect a handfull of users, a dozen or so queues and at most a couple of dozen tickets to be tracked at the same time?

So, I sat back and thought it over. Am I going complety over the top with my design? Definitively. Is it a bad thing? Hmmmm.

Speed is not an absolute requirement. SQLite is not a huge resource hog. And who knows, if the bot works as I designed, it may become more popular than I expect. That happened at times with other tools I made. At least I now have the flexibility to change the underlying storage to suit my needs.

So I decided to continue with Class::DBI.

Replies are listed 'Best First'.
Re: Over-designing....or not?
by dragonchild (Archbishop) on Jan 10, 2005 at 14:15 UTC
    I have started in the past year to run every design decision I make under the microscope of YAGNI. If I will not get to use something in at least three different places, I don't want to refactor to that point. If I will use it in at least three places, then I will refactor.

    The rationale behind three is that if I need it in one place, just do the simplest thing that will work. If I need it in two places, I want to cut'n'paste, just to see what is the same and what is different. If I need it in three places, I will have enough information now to intelligently refactor.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Re: Over-designing....or not?
by Anonymous Monk on Jan 10, 2005 at 14:32 UTC
    I've killed NUMEROUS non-business projects by trying to design everything up front. The ones that have succeeded started small, adding objects and features organically as needed. So just make your database/config settings easy enough to swap out later, and build iteration 1 first with the rough edges. It's something I find really hard to do... I want to break out the notepad and start creating lots of objects, but that (IMHO) is a quick way to end a project.
Re: Over-designing....or not?
by Mutant (Priest) on Jan 10, 2005 at 14:30 UTC

    I think that given that this is a hobby project, then some level of over-design isn't really a problem. You're doing this for the enjoyment of creating something, and you don't have a deadline.

    So some level of over-design isn't really a major issue - who knows, maybe it'll turn out to be a very valuable part of the program.

    In a commercial enviroment, you really have to balance the design, weighing initial programming time against ease of future additions / maintenance. The CS books say more attention should be given to the future changes, but in reality, people don't care about tomorrow, they care about now. And besides, it's never easy trying to predict the future.

Re: Over-designing....or not?
by xdg (Monsignor) on Jan 10, 2005 at 18:25 UTC

    As an aside for future reference of the OP or others, if feel you need a middle ground short of RDB, particularly if the DB aspects not the relational aspects are important, you might also consider modules like Tie::DB_Lock or Tie::MLDBM, both of which offer locking capabilities but allow a simple hash interface to your data.


    Code posted by xdg on PerlMonks is public domain. It has no warranties, express or implied. Posted code may not have been tested. Use at your own risk.

Re: Over-designing....or not?
by mkirank (Chaplain) on Jan 11, 2005 at 06:55 UTC
    If you think in Extreme programming terms
    Keep the design simple
    Turn a blind eye towards future requirements and extra flexibility. Concentrate on what is scheduled for today only
      "Turn a blind eye towards future requirements and extra flexibility." Maybe you misread Kent, not that I'm a fan of him anyway, but you need to be prepared for ANYTHING at any time if you are working that way -- which almost no one ever is.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://420920]
Approved by Mutant
Front-paged by Mutant
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2018-05-26 10:26 GMT
Find Nodes?
    Voting Booth?