Self Organisation

[dynamictiger]

I must admit I am not the tidiest person in the world. Having said that once I understand fully what I am doing I tend to design systems that become self tidying, but this can take years. Unfortunately this is biting me a little bit, so I thought I would ask how others organise. Specifically the question is the development cycle.

I find myself loosing it now and again. Essentially I start with a plan, usually scribbled notes on a back of a piece of paper. I lay out my table structure and relationships and all is good. Then I start designing the forms / queries I think I need. I get to about 50 forms and I start to loose it, as I can't seem to remember all the other things I have already done.

One solution I have tried with mixed success is to keep copying the database as I go and make notes on where it is upto. However, I thought someone else might have a better system or a few tricks on organisation they would be willing to share.

 

[wizcow]

Hi

I make a form with a date and a version field. I imbed a subform with an update field (continous form).
I use this to document all updates that I do.
It seem time consuming to enter every move, but it helps me to know where I'm at.

I hope that helps.

Tom

 

[ritchieroo]

I'm also pretty disorganised... my desk is a pile of scribbled notes, diagrams, and hieraglyphics I no longer understand.

Here are my tips (some of which I may not actually follow):

-- Stop making notes on scraps of paper... get yourself a large hrad-bound notebook (one per project), start keeping a diary. Use scraps of paper for trying out ideas, but throw them in the bin before the end of the day. Write good versions in your diary.

-- Draw pictures: one good diagram is better than a thousand words. But don't forget the words... comment copiously. I have lots of diagrams I no longer understand.

-- Read about object-oriented techniques. Good database design and good OO design are very close. I found "Object-Oriented Modeling and Design", James Runbaugh et al. very useful. Then find a good book on UML.

-- Get yourself a development methodology. I try to use "Extreme Programming" myself, but pick and choose which bits to use check out http://www.extremeprogramming.org and http://www.awl.com/cseng/xp.

-- Finally... 50 forms, no wonder your loosing it!

 

[dynamictiger]

My last project was 127 forms. The approach I used on this was chopped the project up into seperate sections, for example client management, service management and so on. Worked on each as a seperate task group and then remarried the entire project back together and ran more testing to check all functions. Then went through and optimised the code.

Interesting as looking at XP it is similar. Appreciate the link.

 

[The_Doc_Man]

Doc's first rule: Organization and Projects are yin and yang. They might go together, you might need both, but they tend to be OPPOSITES.

Nature abhors organization. Nature favors chaos. (Chaos lies in the direction of positive entropy!) Which is why project managers are generally abberations of nature, I guess...

(Before anyone jumps up and down on my stuff, I've been a project manager more than once. So read it as a rueful grin, not a straight-faced condemnation.)

It is also why it is so hard to keep good notes. Since ALL forms of organization are anti-entropic (including project organization), you have to perform WORK to keep the notes up to date. If you doubt me, look up the Second Law of Thermodynamics.

Doc's second rule: Anything printed has a much longer memory than anything that hasn't been committed to paper yet. So make copious PRINTED / WRITTEN / GRAPHED notes. No matter HOW many notes you have to make to keep things updated.

Use the organization tools of MS Office as your FRIENDS. (Yes, I know they are inanimate objects... but Doc's Third Rule is that we are all crazy enough to believe we can actually communicate with inanimate objects, so go ahead and embrace your new friends.)

For instance, learn how to use PowerPoint to make diagrams using AutoShapes. You can print or review Power Point slides at any time. The list of AutoShapes include flowchart symbols. Then remember the old adage about one picture = 1000 words. (No, that ISN'T one of Doc's rules. It's older than I am, by at least a couple of years.)

Learn to use Excel to keep track of data fields and where they appear with an intended relation. When you are tracking tabular data, Excel excels!

Or, go REALLY overboard. Keep a database of design info so that you can get customized reports. It is a bit redundant, but it can be useful. What I find to be EXTREMELY useful is the ability to take cross-references of code and other data entities. You might do a web search for Access cross-reference tools. I happened to build one of my own. It doesn't take long except for the part that tries to look at code snippets. I won't publish that, though, because of potential copyright issues with my employer.

Learn to use Word to generate tables of descriptive data. Take notes, using Word in Outline mode, to do this. You can get overviews with the first couple of levels, then get into the bloody details at lower levels.

Here is perhaps the most important thing to remember: Treat all projects as being WORTH the effort of tracking what you do. In the long run, projects come back to haunt you. So think of your work now as insurance for later, when the haunting begins.