in reply to Starting a project and landing between a rock and a hard place.
There are a number of philosophies to choose from as you can see. It depends on your own personal style, and your goals.
For example, if you are trying to model some busines process that is already being conducted in an office, you want to spend time talking to people to find out how they do what they do, and techniques like those taught in OO modelling books (you could look at ambysoft) like CRC cards and tossing a ball around (well it's really a lot more involved and there's an art to it) is a good idea. Those cards and the ball are ways to distill logic. Other related tools are use cases, which are little scenarios of what happens when a user of type X tries to do Y, basically a model of what happens across the human-machine interface. This type of diagram doesn't care what happens solely in the machine. It is most concerned with getting the I/O straight.
In the end if you are doing object oriented programming, you want to break it up into objects. The modern school looks for the most important nouns around, say passenger, ticket, and airplane, for one simple example. An older school looks for verbs or server processes, which is really a lot harder to get into your head. If you use nouns (I would) you can say, okay, I'm a passenger, what do I do next. Or I'm an airplane, what kind of information do I know? If you have a lot of information and don't know where to start, you can look for organizing principles so for example if you are doing a business logic project you might want to ask "Where does the money go?" and follow the flow of money, or maybe a purchase order, through an organization. These are the kinds of things that get into those CRC cards too, like What other classes (objects/nouns) do I need to know? and so on.
This is for bigger systems, maybe more than you want, but the general ideas still may work. There is also a group of programming concepts called design patterns which you may read about on the web which can help broaden your conceptual vocabulary if you think you need to get out of the box. Or if you're feeling like a commando armed with Perl and nothing can get in your way you could take a look at Tim Conway's Quantum Reality modules, if he can bend perl around that anything's possible. :)
Me, on a simple project I often just write pseudo code, whether in the browser (commented out, then fill in between the comments if it's really simple), or on paper. Maybe make some little mockups of the screens I want to see. Whatever it is, you probably want to think about what is going to have to get used or maybe extended the most, and see if that could become an object. Some people from the Xerox Parc (Palo Alto Research Center) school like to draw little sketches of people's heads and diagram how they interact with each other, to model a communications system. Something visual and dynamic that keeps your hand moving and head working is good. even stream of consciousness typing is fine if you clean it up later. Give yourself a day or so to leave and come back and look at it again.
The most important thing I think is to document it to yourself as you are going, saying what you are going to do. If once you dive in it starts to get hairy, then you have somewhere to retreat and take a breath, and update your worldview.
By the way, the XP stuff is neat too, I'm talking about the idea of making peace with yourself in the knowledge that this software may never be done. Just find a small part of the cosmic all in your head and make it work. You can create a series of goals and successes when you solve each one and then tear things up if you don't like them.
One nice thing about perl is that it can be lots of things to lots of people. You don't have to recreate structures as if it was Java or C++ or something else that has lots of rules. Though I didn't believe it, it seems to be helpful if you have that perl programmer trait of laziness (well, let's say you want to get something done quickly and easily) for you can then focus your energy on rigorous consideration of what you are trying to do.
Maybe other people will have Perl-specific suggestions. To my mind anyway, it will save you lots of time if you stick with pen and paper for a while. You also will be less disappointed if your thought models reflect the problem you are trying to solve, because a good model of the world is going to give you ahah! synergies, and continue to open doors to realizing things about your problem which you did not see at first.
Finally, if you are already into the project like you said, maybe the most important decision is to ask what simple tasks have I already solved and are definitely working okay. Don't change those. Then be willing to tear out chunks and leave the rest of the monolith standing there, just because if you are doing it on a deadline it has to work, not be pretty. If it is too scary, just tear it all down, it's not worth tweaking a monstrosity because it will just keep throwing you off balance (I know from recent experience). You can then try to step back, break the problem up into black box components which you just have to talk to, not know intimately, and then you can start thinking about how they interact together.
So first step, clear off the desk. Get a big liter bottle of ice coffee or something like it. get a pen and start attacking it anywhere, even on the edges, trying to figure out what you want to have happen and not how you get it done, and while you are at it keep alert for lines of cleavage where the problem seems to fall apart into one or more pieces. These may give you a clue about how to organize your efforts.
|
|---|