Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Project management

by Ea (Chaplain)
on Jul 13, 2001 at 19:33 UTC ( #96440=perlquestion: print w/replies, xml ) Need Help??

Ea has asked for the wisdom of the Perl Monks concerning the following question:

I am looking in the future to what my next program is likely to become and I can forsee that different people are going to want different database connections and/or platforms. What can I do to make my life easier when someone comes back to me saying "oh, could you make it do this instead"? I don't want to go messing in the guts of a program and create incompatabilities while trying to add new functionality.

It's original form would just be one long program in Perl/TK (Java is the other option) providing an interface to a database for a barcode scanner under Win98, but I have my choice of Oracle or Access (and MySQL is always lurking in wings) and, who knows, the platform may move to WinXP or Linux. I want users to install it as painlessly as possible along with the required Perl and TK libraries. Am I looking at simply parsing command line options with GetOpt or should I go full blown control with MakeMaker? (I'm not sure what I should be running make on, tho)

What I'm looking for are ideas on good project management, so that I don't end up down some dark alley late at night. Many thanks:

Replies are listed 'Best First'.
Re: Project management
by bikeNomad (Priest) on Jul 13, 2001 at 19:47 UTC
    You're confusing design issues (how do I make a program that will deal with different databases and platforms) with packaging issues (MakeMaker and make). To answer your question, you have to decide whether these things can be changed on the fly (perhaps by user configuration) or whether you'll be producing specific versions for a given platform.

    Conditional compilation a la C doesn't work too well in Perl, though there's a command-line switch that will run your code through a C preprocessor first. Instead, we generally use run-time conditionals. It is possible to make a module that provides a consistent interface to two or more different modules, so that clients don't have to concern themselves with cross-platform issues.

    You probably will find it easier to stay in pure Perl and have a single version of your program that can run (possibly with different configuration) across multiple platforms. MakeMaker is more of a packaging tool.

    Consider using object-oriented design for your system. If you have two different ways of doing something, make adapter classes (packages) with the same interface that do the something in each of the different ways. This way you can even mix the different ways (imagine having to deal with more than one different barcode scanner on a system at a time, or dealing with more than one database to allow copying and exporting).

      My program will not require changes. (Although, I can forsee the possibility where it would be useful to scan student marks into one database and then scan books into another. OTOH, I should work on my Laziness before I start worrying about Impatience.) You seem to be saying that modules are a good way of simplifying design issues.

      Module Interface design: (never having written a module) Should I put all of my different database connections in one module, my input methods into another and keep the logic in the main program? Going through the Cookbook, I still don't see in what manner I should divide up my program into different modules.

        I find it virtually impossible to believe that your spec will never change and you know up front that changing circumstances will never cause you to need to modify your program. The real world simply does not, in my experience, work out that way. Nor do I know anyone else for whom it works that way. (Well I do know of exactly one widely used program which is no longer being modified in any way, shape, or form.)

        Therefore if you wish to avoid digging a pit for yourself, I strongly recommend starting with the opposite assumption. Assume that your program will change. Assume further that you don't know how it will change. With these two assumptions you should now see the benefits of trying to modularize the internals of your program as much as possible. Break it up into functions. Make each function do one thing. Make the name of the function say exactly what that function does. Avoid globals. Use to remind yourself of globals you might have missed. So on and so forth.

        If you do this, then you will be ready to face the inevitable point where reality meets your optimistic hope that you can just write your program and it will really, truly, be done.

        <quote>My program will not require changes</quote>

        Hmm, where have I heard this before? I thought you were already talking about changes. My experience is that once a program is useful, people will come up with more and different things they want it to do. Assume it's going to change.

        There's roughly two different things you can do with a module: define new packages (also called namespaces or classes) with their own subroutines (and maybe local data) and/or add subroutines (and maybe data) to existing packages (like especially 'main'). You can accomplish the same thing with code in a single large program, except that it's bigger, harder to find things, and impossible to re-use that way. By breaking up your program into modules, you can re-use common functionality. If you've designed it right, that is (modules are no guarantee of reusability, any more than object design is).

        I use object-oriented design, in which I view my programs as a group of collaborating objects which call on each other to get the job done. Objects have a single responsibility.

        Inheritance (@ISA in Perl) can be used where you have common behavior that you want to share between packages. You can put common behavior in one package, and inherit others from that one, adding specialized behavior to each of them.

        I don't know your program, but one way to start breaking it up might be to ask where do I have behavior that might change for different platforms or hardware?. If you have several kinds of barcode readers, for instance, you might have a common package ("base class" in object-speak) that several reader-specific packages inherit from. Whether you put these in separate files or the same file depends mostly on how comfortable you are with the file sizes and number of files. It's easy to change later, assuming you don't share lexical variables between multiple packages in a single file.

Re: Project management
by arashi (Priest) on Jul 13, 2001 at 19:56 UTC
    Here's my idea of good project management:

    Your initial steps should be spent with both project management and the end users of the program to determine what features and functionality the program should have. Be sure to get a complete description of everything required in the program, and make sure that all people involved (programmers, management, and end users) are on the same page.

    Use modular programming, separating each function of your program into a self contained module, and bring each module to functionality in the program when it's completed. Continue talking with project management and the end users to make sure the project hasn't deviated from expectations.

    When the program is finished, if you kept talking with project management and end users, your program should be exactly what was expected.

    I've heard that some programmers don't like talking to, or can't relate well to end users. If that is the case, hire someone to be a mediator between the two groups (a geek/common translator if you will :)

    I hope this helps you find your answers, I'd like to hear what the other Monks think about this, so I can improve upon my own ideas about project management.


    I'm sure Edison turned himself a lot of colors before he invented the lightbulb. - H.S.
      We did fairly well with the user-programmer interaction in the first go and it helped keep our feet on the ground. The best thing to have is a Kendal. (she's our best secretary. good with computers, but boldly interacts with them in her own way) It took her 2 minutes to identify my biggest oversight in the scanning routine as she laid a book on the keyboard to make some room to scan. :0

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://96440]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2021-11-27 23:38 GMT
Find Nodes?
    Voting Booth?

    No recent polls found