SPUG:Designing Programs

Marc M. Adkins Marc.M.Adkins at Doorways.org
Sat Jan 11 13:03:11 CST 2003

> I have a question. How do people design large programs with Perl?
> Do you start typing code? Or do you spend some time designing it
> on paper?

My goal in any project is to break out chunks until the main program is
essentially one page of code.  I rarely achieve this goal but it helps to
prevent the dreaded monolith of doom.  No one likes a 10,000 line main

Since my formative coding years were during the OO boom of the 80s the
chunks I break up into are often classes, I tend to think in terms of
classes.  This has the beneficial side effect of allowing me to search CPAN
(or whatever) for existing classes that do things I need.  Think LEGO
bricks...is there one that does what I want or do I have to fake one on my

The other major chunks are basic coding entities of various types.  Another
response to your email mentioned presentation vs. [business logic] vs.
database.  Not only do I slice things by what they do but by how it gets
done.  For example, in one project the working code ('business logic') may
be in a class that gets called in the main process, in another it may be
ensconced in a separate process on another machine.  These decisions are
based on requirements such as the scale of the system, tools available, and
the schedule.

With respect to the design process in real (people) time:  there is always
some design on paper or within my brain.  My brain holds a lot of code
(which is why I can't remember anyone's name after I meet them, or even my
own telephone number on a bad day) but even so I usually end up with
something on paper.  I usually use small pieces of paper, just as I try to
code in small modules/objects/functions, and before I start I tend to have a
few sitting at my side that represent my 'design'.  If I'm working with a
group, I/we transfer this to a design document of some kind for the sake of
the group.

At some point, though, I do fall through to 'feeling my way' through the
actual implementation.  My first goal is always to implement what I call the
'skeleton' of the code.  This is an end-to-end implementation whether that
means writing the top-level loop of a simple filter or creating a basic
GUI/backend/database process structure so that each bit of functionality can
be placed in its overall context as I work on it.  Within the skeleton I
tend to do incremental development, with customer feedback as a constant
input (where there is a customer, somewhat less so in these jobless days ;).

I can't remember the last time I wrote anything more than a simple text
filter in its entirety before testing anything ('big bang' testing).  The
purpose of the code skeleton is to allow me to test as I go along.  In this
fashion I avoid finding out at the end that my front-end/back-end
communication mechanism is bogus and has to be replaced in all 82 places it
is used.  By the third small chunk of functionality I know that it works and
don't have to think about it anymore.

During implementation I often determine that I need more 'helper'
classes/modules.  These are often project-specific as opposed to generalized
entities that can be gotten from CPAN.  This tends to make the actual
development process jerky or 'quantum' in practice as I'll be working
smoothly on incrementally adding functions and then suddenly realize that
I've written the same code eight times and stop and pull it out for reuse.
The same for small development tools.  This is a critical spot, though, for
it is where many good programmers tend to over-engineer.  Using the same
code twice isn't reason to build a class that's engineered for the ages.
That's a waste of time.  Wait until you're sure that the cost of making the
class/tool is less than the cost of just duplicating the code with a text
editor for the rest of the project.

All of this is really kind of vague.  When coding on my own I vary all of
this as I see fit and break my own rules for various reasons when the
situation warrants.  When I code with an established group I try to fit into
their pattern of coding.  Flexibility is important in delivering solutions
on time and budget.  The opposite of flexibility is usually how DOD projects
end up costing so much.

On the other hand, there are times when really extensive, fixed methods are
justified.  Like large DOD projects.  Medical systems.  Air traffic control
systems.  Anything big and/or mission/safety-critical.  There is a limit to
how many people can work in a flexible development environment without
structured communication, documentation, methodology, etc.  Above 7-10
people you suddenly need extra people just to manage the communications flow
and extra people to manage them and so forth and suddenly you have a cast of
thousands.  There is a sudden drop-off in the number of lines of code per
person-day that can be effectively generated and it's all about project
scaling issues (just as many of our real problems are about system scaling

Finally, please take all of this with a grain of salt and read other
responses.  This is a brain dump and I'm on the 'cowboy' fringe of software
development.  Your mileage may vary.


More information about the spug-list mailing list