Managing Large Projects (1 Viewer)

[Thales750]

The only databases I've built in the last few years are very large, with thousands of objects. In the last few years some of the system have been built in a modular format.
So new major pieces are developed in completely different files. The tables that are specific to the module file are all local for the initial design and then moved to the SQL Server. Whichever existing tables are general purpose are linked to the development file.

Major Object names have a prefix that refers to the initial development file. For example; the latest Modular Development File imports data from spread sheets and organizes the data for general BD use. these Object have a prefix something like tblBom, frmBom, qryBom, etc.

What are some of the problems you foresee with this approach?

 

[Eugene-LS]

What are some of the problems you foresee with this approach?

None at all!

 

[The_Doc_Man]

For single-person projects, whatever works for you is what works. Make your own rules. Use your own conventions on naming. The only hard-and-fast rule in that context is "stick to the rules you decided that you needed."

If this is a multi-person project, your problems will be coordination and setting precise rules on allowed vs. disallowed interfaces. People will want to go their own way on assignments, but the key is to make interfaces a STRICT (and I mean STRICT) point of agreement. Treat subs as "black boxes" and forbid anyone from using "insider information" as a short-cut, because that leads to undocumented side-effects. If ANYONE wants to use side-effects, cut that off at the knees. When starting multi-person projects, establish a fence around each assignment and if interfaces are needed across the fences, hold a meeting to agree upon how it will work together.

Early in my career, LONG before Access existed, I supervised (and contributed code to) a project for a company that made industrial control systems. Our products including petroleum-industry pipelines and building energy management systems.

We started a six-person project to upgrade an existing system that used a home-grown operating system and hard-coded damned near everything. We switched to the (relatively new at the time) RSX-11M O/S, which included memory management, multi-tasking time-sharing based on task priority (including task wait-states and the possibility of swapping), and generally written independent device drivers that obeyed rules on interrupt handling, device timeouts, etc. Before we wrote a line of code, we talked about interfacing and how things HAD to work in a way that didn't involve convoluted code actions. We had to SCRUPULOUSLY resist code practices that were prone to introducing side-effects through excessive use of global variables across multiple tasks. We had a "bible" that recorded our decisions including a change log for any action that we decided was originally a great idea but that just wasn't practical.

The product we created helped major oil industry companies run pipelines 1500 miles long, crossing many state lines. We had code built in to help with compliance for interstate commerce commission rules, and we even had international customers. For instance, we ran several systems for the Venezuelan company Maraven (a nationalized corporation). We worked with Atlantic Richfield and with Union Oil. I've lost track of how many companies were involved, but we had over 60 major pipelines active during the peak of our production - before the company got bought out. That's a different story. But the point is, we had considerable success in our efforts because we were careful up front in coordinating the work of six programmers to implement a self-consistent project.

 

[Pat Hartman]

I too started with large multi-programmer, multi-year, multi-million dollar projects. The more people involved, the more critical "control" became. Back in those days, we were learning about structured programming and coupling and cohesion which sadly, have been lost to the dustbin of history but should be revived since they are as relevant today as they were in the early 70's. Coupling is the connections BETWEEN modules/functions and cohesion is the tightness with which the inner code adheres to a single purpose. You want your procedures to be HIGHLY cohesive and LOOSELY coupled. This goes a long way toward minimizing unintended consequences of you make changes to something.

Every new release of Access/Office/Windows breaks something unexpected (no one expects the Spanish Inquisition). That tells me that the MS developers do not understand cohesion and are reusing objects that should not be reused.

If you find yourself wanting to reuse a procedure and you convince yourself that you can just add an If here and that will solve the problem, you are misunderstanding cohesion. If you really want to reuse the code, break it up and have the original procedure call subs for the common stuff. Then have a new procedure call the parts of the original that were broken off.