I have been developing an application for EMS* Squads and volunteer fire departments. This project has a CGI frontend, using the MLDBM abstraction layer over DB_File for the database backend.

I have learned many, many, many things as I developed this project in a rather ad hoc fashion, implementing things on the fly as I learned them. One of the things I have learned is to *not* do that. While I learned alot by experimentation, the code base was riddled with kludgy mechanisms and practices that were anathema to maintainability and readability. The project grew, and grew and got more and more out of control, until I had to rewrite it using the ideas and concepts that I had learned throughout my trials and tribulations, which I will present the lessons of now:


I have learned that programming is a multi-faceted discipline that requires many different types of abilities combined in different ways for different situations. Some of these talents can only be gained over time and through experience.


* EMS = Emergency Medical Services

redmist
redmist.dyndns.org
email::redmist

Replies are listed 'Best First'.
RE: Musings of a Monk
by h0mee (Acolyte) on Nov 12, 2000 at 16:07 UTC
    I can't agree more! With one project, Redmist has encapsulated a lot... The first thing I learned as a professional developer is: A Good Design is *the* most critical thing in a project. This is fundamental advice given over and over, and it's so very true. A good design will save you 90% of the hassles involved in coding- and will mean the difference between a 10 day project and a 10 month project.

    I've also learned that whether you realize it or not, much of your code and thought is going to be geared towards repeated code. The master of implementation is someone who quickly realizes common data structures, pitfalls, and manages to automated them...
RE: Musings of a Monk
by kaatunut (Scribe) on Nov 12, 2000 at 18:21 UTC
    Agreed... I don't have experience with large projects like you do (or with coding in general), but I've had quite a few personal projects with grand plans that I gave up on because I ran into dead end and realized my design really sucked, or encountered a problem I simply couldn't design a solution to. Lately it's gotten a bit better, possibly because of increased age, but maybe because I realized something:

    1. If you run into problem that you can't solve right off because you have no clue where to start and how to build it, redesign, it might be because you don't really know what you're doing. Stop, have a break, come back, write down (in comments is cool) what you're exactly doing, what is the problem, and everything like you were describing it to someone else. Then read it.
    2. Even better, explain the problem to another proficient coder.

    I realize that sounds obvious but I didn't actually think of that in the first 5 years of my coding, so it's possible someone else didn't either... especially if this someone else is as unsocial as myself. Like it or not, coding is sometimes social practise.

RE: Musings of a Monk
by brainpan (Monk) on Nov 12, 2000 at 16:35 UTC
    In reading who you're doing this for, visions of (being held responsible for) coding a program to coordinate the deployment of emergency vehicles comes to mind. What kind of project is this?

    And no, I don't own 27 pairs of sweatpants.
      I don't plan on my software ever getting into the dispatch center (which is where it is <emp>incredibly</emp> important that the software be stable and bug free).

      This piece of code will be an information management system. It will manage data like:
      • Name (with rank).
      • Address.
      • Contact information.
      • Number of members (volunteer firefighters or medics).
      • Number of firefighters/medics on call (and available for mutual aid*).
      • Response time of a certain firefighter/medic.
      • The firefighter/medics placement on a map (and optionally, in relation to an incident).
      • An MOTD regarding any local or national policy changes.

      Departments will implement the program voluntarily in addition to any system that they might have already set up.

      * Mutual aid: A system in which one fire department can call another for help if a situation gets larger that they can handle alone. This system works on the premise that not all fire companies will be busy all the time, and can afford to help others out in certain situations.

      redmist
      redmist.dyndns.org
      email::redmist
RE: Musings of a Monk
by jptxs (Curate) on Nov 13, 2000 at 02:45 UTC

    The project I'm working on has inspired the same realizations for me. That's what inspired Monk Project Section.

    "sometimes when you make a request for the head you don't
    want the big, fat body...don't you go snickering."
                                             -- Nathan Torkington UoP2K a.k.a gnat