Hi all, I'm in a situation where

[Darrylles]

Hi all,

I'm in a situation where I have inherited various Access applications.

The applications are quite large and very complex due to the developer having absolutely no RDBMS training and absolutely no MS Access training.

He had basically over a number of years, 'picked up' how to achieve solutions. These 'solutions' involve:

a) no relationships between tables (that's a lie - ALL pk to pk) and hundreds of 'em.
b) no VBA (all macro - with no comments!)
c) no comments for ANY object whatsoever.
d) no application documentation except for 3 pages on how users click buttons.

I am qualified in RDBMS design, and software development to degree level. I've 8 years experience in commercial software design.

What I want from suitably experienced Tek-Tips people is: your view of the a..d items above.

If you could detail your experiences (succinctly) when coming across an application as above - it may well help my MD understand that some skill does exist in maintaining and repairing unskilled applications.

It may well make the md understand that 're-write' is pretty standard.

It seems that a self-learned 'shelf-filler' can do the job better.

Kind Regards,

Darrylles "Never argue with an idiot, he'll bring you down to his level - then beat you with experience."

 

[Steve101]

Hi Darrylles,

No need to introduce myself We've chatted on a couple of other threads.

I have spent a lot of time maintaining exactly the sort of databases that you are talking about, and don't feel alone; there are stacks of them.

Your points (a) through (d) are all fundamental and of course indicative of poor systems practices from inception through to deployment. There are however a number of other angles that need to be factored into the equation (and you may need to put yourself in a management/ devils advocate role here)

1) Do the systems work satisfactorily (by this I mean that they deliver to a greater extent, what the user's want).

2) Can you convincingly demonstrate a "cost - benefit" associated with a major re-write, and

3) Can you produce a schedule which would allow you to re-develop the systems in parallel with keeping the existing systems operational.

4) You dont mention anything about naming conventions. I'll assume that the existing systems dont have any, and that object naming is all over the place. Is this correct? After counting the numbers of objects, this is always the second thing that I look for regarding "quality" of the application and experience of the developer(s).

5) Regarding (a), how sound is the quality of the underlying data model(s). With respect to data normalisation principals, is there data repetition all over the place, or is the damage "contained" by virtue of the way people do things.

I have been maintaining and enhancing one large system, exactly as you describe for about a year now. The user (a manager) has always had "ownership" of it, and notwithstanding how bad it is, its "his" system and it "works" for 90% of the things he wants. Because of this he (or rather his budget) wouldnt entertain the cost of a total re-write.

In my role as a maintenance programmer for this system, I've come to accept that I apply good practices to the bits I'm working on, and the enhancements I make, and improve the quality of the system in "slow time".

I'm of course working on a system (as above) which the user "owns" and hense I dont have to defend the sins of past developers.

I guess the above are some of the non technical considerations which you have to take into account as you put together your strategy and options for how to tackle this challenge.

All the best, and remember to go 'gently gently'. Try not to be over critical of the existing system and past developers. Focus on how you can improve the systems, rather than the negatives of the current systems; there are subtle differences. Also try and use a "divide and conquer" approach. If you and your boss are still getting to know one another, then you might be better off focusing on and improving one key area of the systems (and "proving yourself" this way), than trying to convince them that all systems need to be re-developed. Bottom-up and top-down approach. I hope that this does not sound like a whole lot of "motherhood", but is useful supplementary advice.

All the best,
Cheers,
Steve

 

[Darrylles]

Hi Steve,

We meet again.
I opened this email notification straight after responding to our 'barbs-up' campaign.

Thanks for your response, and I'm pleased to say that I have thought already about each and all of your comments (I'm therefore not incompetent and obviously following 'standard' practise regarding RDBMS / application design). i.e. I'm not alone.

Before saying anything else, the situation is a pure 'fire-fighting' one. I came from a RDBMS called Uniface, 9 months ago and had to land running with Access.
I pretty well knew VB from personal experimentation, but Access is a 'mind-shift' in comparison to both VB and Uniface.

You probably haven't heard of Uniface, but it's an experience that would blow your mind if you're keen about your trade. After you've designed the table structure, the application development is a maximum 10% of the time it takes to develop in Access never mind VB.

Anyway - I've got your points, no reason to go into 'em - you've got my situation to a tee (the app. is also my directors 'baby').

I do however have responsibility for IT in general throughout the company and 'IT resources' are viewed as expenses rather than 'consumables'. One more addition to a massive headache.

Have you tried maintaining an IT system on 8-10 year old machines that constantly fall over?
Try also running a 120 meg Access database - this size purely due to poor table design / data duplication on 15 outdated clients (ok - only 15, but it's enough when they are all different in all respects).

I also know the meaning of 'enhancements in slow time' - it's just not enough in this case.

Sorry mate, using Tek-Tips like a chat room.

Thanks for your response,

Regards,

Darylle








"Never argue with an idiot, he'll bring you down to his level - then beat you with experience."

 

[Steve101]

Darylle,
I've heard of Uniface, but have never used it. Do you plan to introduce it into your environment, or is this not a possibility (eg. because of cost?)

Yes, it sure is frustrating working with outdated hardware and limited resources. Regarding the 120MB Access database. Have you considered making a case to 'upsize' it to a SQL Server backend on a new server machine. I recognise that this will do nothing for the inherant architectural problems, but it might be a good intermediate stepping stone.

Anyway, that was just a throw-in. I absolutely don't know enough about your environment. Just use the gently-gently approach (which can be hard), and good luck,
Cheers,
Steve

 

[LLudden]

I've had a fair share of those "fire fighting" projects in the past. I can't think of a single case where the product was going to continue in use over a period of time where it wasn't, sooner or later, decided to just redo the whole system from scratch and do it right. Generally what this meant was a "feature freeze" on the old product while the new one was being developed.

I remember all to well the 35 hr stretch to fix a bugged piece of software, which mainly consisted of a 9000 line CASE statement in C, or the three days fixing someones GIATT* database for a point of sale system. Generally what had to happen to get the problems fixed was for there to be significant downtime during one of the "fire call" repairs. This raised management awareness of the problem in a way not much else can.

 

[zambezibill]

It might be a good time to invest in a 3rd party support application called SpeedFerret by BlackMoshannon (there's a website available). It will do global (application wide) searches and updates (among other things) and might save you a world of time in locating the instances a field name, control name, variable, etc. are used. That is if you are stuck with the status quo.

Alas, I have produced applications while further down the learning curve and trying to get them up to spec subsequently all but moved me to tears. Going back to my own work, it was a tossup as to whether it was more cost effective to tweak or trash.

Personal opinion: go over the table structure, maybe printout the tables, fields, data types, etc. and decide if the back end is reasonably normalized and logically constructed. IF so, then keeping the front end may be a go. Otherwise, making all of the front end changes to track a backend overhaul will be a losing cause for someone (probably whoever is paying).

Cheers, Bill