Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Re: Multilevel flexibillity

by Abigail-II (Bishop)
on Jun 24, 2003 at 00:03 UTC ( [id://268353]=note: print w/replies, xml ) Need Help??


in reply to Multilevel flexibillity

I don't quite agree. Generally, flexibility is a good thing to consider when writing or designing a program. But like other good things, flexibility comes with a price.

Proper design doesn't mean you focus on one thing, and let that thing dominate all decisions. Creating a good program means finding the right trade-offs. You have to make compromises. One of the obvious prices of flexibility is simplicity. The more flexible a program is, the less simple its source code and interfaces will be. The most flexible program isn't necessarely the best program, and neither is the simplest program. Instead, the best program is the one that has found the best balance between flexibility and simplicity. And all the other things to consider: resource usage, security, maintainability, etc.

Replies are listed 'Best First'.
Re: Re: Multilevel flexibillity
by zby (Vicar) on Jun 24, 2003 at 07:21 UTC
    I don't argument against design - planning the future changes of the software is a part of the desing process. I just concentrated in my meditation on this isolated part of the process.

    Perhaps the overall complexity of the flexible solution is bigger, but it is quite usuall that it means shifting the complexity to some other place and make the code simple. Once more a good example of this is templating where you don't hardcode the interface design in your program but rather leave it to some other mechanism. For complex sites your program stays much simpler that when you hardcode page generation in it.

Re: Re: Multilevel flexibillity
by petesmiley (Friar) on Jun 24, 2003 at 19:56 UTC
    I think it's interesting that he considers flexibility so important. The first thing I look for is a working program. I'd say about 70% of the software I've run into doesn't completely work. Sometimes software just outright bombs (not the most common case, sometimes it flops around on the ground before it dies). Hell, I've had the gorey displeasure of having to fix a couple of programs written and abandoned by a sloppy coder.

    Sometimes I wonder how software ever even makes it past a client without being evaluated to see if it works. I've seen plenty of time and money spent on programs that don't work.

    I say, if you don't have something simple that works, then you definitely won't have something flexible/complicated that works. I've seen plenty of flexible programs that haven't worked all because somebody worried about the chrome before the engine.

    Just an opinion from a guy who's had his share of deadlines.

    smiles

    PS If flexibility is so darned important, then I think no one would write one-liners.

Re: Re: Multilevel flexibillity
by tilly (Archbishop) on Jun 25, 2003 at 12:53 UTC
    I don't find this an obvious trade-off.

    In fact it seems that very flexible code is often also very simple. This is particularly common when flexibility has been achieved by a modular plug-in architecture, and new features have been added through plug-ins rather than through complicating the core design. (There are, of course, significant overheads in resource usage with this approach.)

      Well, I think that proves my point. Surely code that doesn't have a plug-in architecture is less complex than code that doesn't have the additional code to deal with plug-ins. But it's also less flexible.

      Abigail

        A core with hooks for plug-ins, and then a few plug-ins that come standard often is less complex than monolithic code which provides natively the flexibility in those plug-ins. This goes double if the monolithic code attempts to add functionality to compensate partway for what in the other architecture can be safely left to optional plug-ins available elsewhere if you care.
        The overall complexity might be bigger. But I would argue that the overall complexity is not the most important factor in understading the system. The important factor is something that I would call the 'complexity of the viewing window' - that is how much complexity there is in each whole 'view' of the system. This is quite vague thought - but I'll try to explain it.

        With good plugin architecture you can partage the whole code into isolated parts with low complexity, you can view each part with a low 'complexity of the viewing window'. What is more you can view the whole system with a low 'complexity of the viewing window' too - since you don't need to know all the details of how those plugins are coded - you just need to know how they are assembled.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://268353]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (3)
As of 2024-04-24 18:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found