in reply to Interface design
in thread Project management

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

Replies are listed 'Best First'.
Re: Re (tilly) 1: Interface design
by meonkeys (Chaplain) on Sep 27, 2001 at 12:40 UTC
    Assume that your program will change. Assume further that you don't know how it will change...
    I like this. I had to say that in addition to a ++! As usual, excellent advice from tilly. All too often I get bad lazy and just assume that my software is a rock and an island. The real magic is in the chunnel! Just like MI2.
Re: Interface design
by Ea (Chaplain) on Jul 18, 2001 at 14:57 UTC
    :)
    This was the whole point of the question (which of course gets muddled as brain tries to dump to keyboard). I've got one setup where I know that the spec won't change for a year or two and we worked out what the users really want/need from version 1.0. The next version is to be a lot more presentable and in it's avarice, the department would like to sell it to the other departments, whose setups I will not know ahead of time. Good suggestions, both of you. I'd thought of the easier ones, but strict.pm and OOP hadn't occured to me. I shall be following the latest module thread with interest.