Lone Ranger, Rapid (Slow) Development (1 Viewer)

Well, I just read Tony's post in Jon's sticky at the top of this forum...I am definitely a beginner, but I already knew that!

So, feeling a bit lost and frustrated here. I am a Lone Ranger on developing several databases for our plant. I took a few intro classes about 10 years ago, and own a couple of books, and have access to you all! One of the books I am trying to understand is Database Systems: Design, Implementation and Management, by Coronel, Morris and Rob, 9th ed.

With the current database I am working on, it's like an ordering program, but with different needs for us. I am close to getting a working application, but am reviewing some of the data, relationships and such.

The approach I normally take when creating something in Excel or Access is to start building it as I think about what I might want or need. (Obviously this leads to problems, which is the leaky boat I find myself in. I want this application to work well, and I want to develop it with the best techniques. So, I found myself reviewing our company’s business rules, descriptions of operations and such to make sure that I have all the possible entities, attributes, relationships, etc. needed. Then, I found that an ERD would very handy, apart from the Relationships window in Access. I’ve tried ArgoUML, but found it not that user friendly and the help is limited.

I am attempting to use Excel to help me diagram this out and uncover possible errors or missing data. I would like to get to the next level of developer, but this is definitely taxing!

What methods do you use to go about the design phase? I need to become more thorough in this phase before I open Access.

Thanks!

i basically design as i go. I need a tClient table, so I make it. I need a tPurchase table then I make it.
Then as I try to fit them together, I see I need another table or field. So I add it. And continue to modify as I need it.

Its a design and build at the same time.

How long have you been doing it this way? Is this your profession?

Some simple - but far-reaching - rules come to mind.

Old Programmer's Rule #1: If you can't do it on paper, you can't do it in Access. Meaning, if you are not familiar enough to at least symbolically draw a picture for data transformation for each process in your business, you don't (yet) know enough to actually code or implement anything yet.

One approach I used a long time ago was to create a "bible" for the project. I examined the project top to bottom, inside out, and back to front. I determined the general data flow involved including identification of each module (at least at a high level) that had to touch the data sets in a given sequence.

Another approach I have recommended involved investing in a large box of sticky notes, a big dry-erase board, and some suitable markers. As you identify new business entities and/or relationships that must be described by tables, put up a sticky note on the board and write on it whatever data elements you identify as being of prime significance to the process. Draw lines between the notes to represent relationships. Draw lines in a different color to represent transformations (which could be insertions of new records or updates of old records). Capture that information as part of your design guide. Note that the sticky-note and relationship lines will DIRECTLY contribute to the Access Relationships diagram that is one of the database tools.

Old Programmer's Rule #2: Access won't tell you anything you don't tell it first (whether actually providing the data or merely providing the method). Meaning, know your OUTPUTS in order to work backwards to determine needed inputs. This is in line with one of the Niklaus Wirth (father of the PASCAL language) observations, which I fully accept, that 80% of all programming problems stem from poor data definition.

Oh, there is nothing wrong with building parts of your structure as you go, but remember that if you go too far, you will be a victim of that old rule (that isn't one I claim as my own): If you don't do it right the first time, how will you EVER find time enough to do it right later?

This is not to say that you should freeze yourself into inaction. It is a matter of balance. If you identify the really significant structures up front, the extras can be added later. But there IS no substitute for spending a little time on design before spending a LOT of time on implementation.

I think Ranman has it though.

Happy hacking.

There are really 2 approaches

1. is to carefully specify the project. You spend ages agreeing inputs and outputs, and spend a lot of money getting something that still doesn't work

2. the second is to trust that the programmer understands his stuff, and can build a solution tailored to the design brief, that works. Doing it this way needs most likely needs some stepwise-refinement along the way. You do something, it's not quite right, and you improve. This solution methodology is far more productive than method A. You probably won't get a firm quote for the work (although you might a maximum estimate), but it will cost less than method A.


You can replace cost with time, if you are doing the project yourself.

We tend to whiteboard and paper the exercise first for about an hour or two first, just to get the Outputs, Processing and Inputs clear in our heads and the end users.

We then go away and think out how this translates to reports/forms and ultimately the tables required to store the appropriate data.

Build something ragged around the edges , test, if it appears to work get someone to beta test on live data, refine , clear up the messy bits, then document.

Then come back to it 3 months later for a re-write gloss over, when they've altered the process

Minty,
Don't you get a lot of nice to haves the first 3 months before a total overhaul ?

Here it is sometimes even worse :
After a few months of developing and starting to deploy the amazing access app some manager comes by and just say 'nope we are not going to use that. Stick to the endless excel files and email'... That is worse than altering the process as a programmer.

Grumm, that is when you find a convenient window on a high floor for a managerial defenestration. The "splat" should be particularly gratifying ... even if it only happens inside your head.

Thanks for the laughs, guys!
Doc, I was hoping to hear form you on this, figuring you for a seasoned veteran, and the way you explain things. I am attempting to "Bible" this project right now, as well.

I like the whiteboard idea, but I don't have wall space for that.

Dave, I am the only one working on this project - with no professional experience and two MS Office classes 10 years ago.

Minty, I wish I could go away for a few months. I'd probably go to the mountains to clear my head and focus on the big picture; maybe invite someone I'd like to "splat"!

You know, sometimes I feel like I'm hacking - discovering that for certain operations I can script them, make calls to the WAPI, etc. But that is like one of those rabbit trails in Alice in Wonderland. Or a hole or whatever she went into. Or like Luke when he had to face his fears on Dagobah, I think.

Any other ideas on how you keep your documents organized would help too, such as typed up design docs.

Appreciate you all! I would like to meet some fellow developers, too. Anyone on LinkedIn?