2 steps forward 1 back (1 Viewer)

The Design Process - 2 steps forward 1 back

I'm curious I've been designing relatively basic databases mainly for my own purposes for about 5 years now - (I've actually been doing it for longer than that but I don't rate anything I've made before then enough to consider it as useful).

Most of the better ones I've totally re-designed from the ground up at least once.

Seems to me that good database design is particularly incremental and there's a significant amount of intuitive subjective design to many parts of it particularly layout. So in that respect about 50% of good design often comes from the refinement of the thing once up and running. This is relativley large percentage and an indication of just how wide of the mark I can be when setting out on a project.

I've hit a few hurdles in a few databases which have been major and really required complete re-design. Fine enough when its myself setting out the design criteria I've got no one to blame except myself but this is even more likely when others design the spec.

In particular I designed a timing application for a friend. It takes times from radio frequency identifiers and calculates times over a variety of courses. It was heavily stressed to me at the time that they needed to have a facility to calculate Last Seen times (technical facility to have the ability to calculate times based on the last recorded time on a mat, mats picking up multiple times when people go across them) Although not hard it doubled the coding. Needless to say the client has never used the facility!!!!! I'm inclined to go back and design a simpler system and completely ignore that spec! As I do find it annoying that there's all this code just bloating the thing.

I'm curious to get others opinion but

Is everyone in here able to make great applications from the off or have you frequently started out and gone back and to a certain extent started again?

or

In your major applications do you have plans to go back and do a complete re-build from the ground up..???

Re: The Design Process - 2 steps forward 1 back

Lightwave said:

I'm curious to get others opinion but

Is everyone in here able to make great applications from the off or have you frequently started out and gone back and to a certain extent started again?

or

In your major applications do you have plans to go back and do a complete re-build from the ground up..???

Click to expand...

In my opinion, there are really two tiers/layers, the back end (tables) and the Application (front end)

Back End

With regard to the back end (tables) I have rarely had to start over or do a complete re-build from the ground up once I started following the rules of data normalization.

I DO NOT let the User Interface (Application/Front End) dictate the back end design.

Front End

As work flow changes and/or requirements change, I will create a new User Interface. This rarely requires any redesign to the back end. I might have to add a table or a field. It usually is just adding records.

Lightwave said:

(I've actually been doing it for longer than that but I don't rate anything I've made before then enough to consider it as useful).

Click to expand...

I would not discount any database that you have created. IMHO, learning what NOT to do is just as important as what to do.



..."Thomas Edison, who said, "I have not failed 10,000 times. I have successfully found 10,000 ways that will not work." REFERENCE The World Bank. 1994. World Development Report 1994: Infrastructure for Development. New York, N.Y.: Oxford University Press..."
http://darwin.nap.edu/books/NX006728/html/35.html

I believe that to be so true when working with computers and programming.


That is why my current siggy says:

Programming: Nine different ways to do it right, a thousand ways to do it wrong.

Click to expand...

i personally think the back end (table design) is by far the most important. Get this right, and the form /query design becomes easy (easier), and intuitive. Get it wrong, and you can get very very tricky problems

Now problems come from two areas, in my experience

1.
they didnt explain what they wanted properly
you misunderstood what they wanted
they didnt define the system correctly
so the table design ended up defective, and although it could cope with 98% of the stuff - the 2% of special cases couldnt be handled with the existing structure

2.
after they start to use the database, they realise how powerful it is, and start to make more requests. some of these are realtively easy - but some require a re-design of the table structure - as you wouldnt have done it that way had you known


3. as i say, get the tables right, and the application/interface is the easy bit - although it still takes time building in the necessary defensive robustness to stop then doing things that dont make sense - eg silly dates/values etc etc

i would say a good 50% of programming at least is concerned with interface robustness

Niklaus Wirth, inventor (author) of the Pascal language, was once quoted as saying (and here, I'm paraphrasing) 80% of all program problems stem from bad data design.

I rarely have to go back and do total rewrites, though there have been times when I have had to revisit modules several times.

I hope that this is not total arrogance on my part, but I find that I make fewer initial mistakes in a design now than I used to. I would LIKE to think it is because somewhere along the way, I finally learned something useful. But I cannot swear to it. Could also be that I'm just on a string of good luck right now. Or dumb luck.

Perhaps one of the things I have learned that is IMHO very important is to spend a little extra time on design issues up front. Of course, there is a point of diminishing returns, but a little extra design time up front really shortens the time you spend later when it gets to be "down in the trenches" time.

If the end user is the designer then you would obviously want the best out of your db. You see something "cool" somewhere and you want it, what do you do? Implement it on your db

That said, the changes you make shouldn't affect your backend, only FE changes. If you find yourself having to keep changing the backend then my advice would be "do thorough planning" and not just rush into building it because you have a deadline. You really want to get it right once, and once only. There are certain circumstances where a change to the BE is inevitable maybe due to drastic change in business organisation or moving from one db platform to another but in the majority of cases change in business needs should not have an effect on your BE if it was properly thought out.

Of course changes to the FE happen quite often, not because of a bug or poor coding but just simply because your client or users want extra functionality or as mentioned before, they see something cool somewhere and want it I'm sure you won't complain because that's your source of income

So in my case, I don't see myself changing the BE, only the FE.

At the first stage of performing a requirements analysis, don't rely solely on what your clients has told you, do some research about their company/business and introduce your own ideas that you think will fit into their business model and maybe they might say "oh, that would work in the future, maybe we should have it now". Always try to foresee future requirements and when you build the BE, don't build it only to accomodate current needs, build in such a way it is scalable. There's a caveat to this though, don't overdo it.

Plan, plan, plan, design prototype, show prototype to client, rethink design, plan, plan, plan again, build, plan, build, show final result, make small and final amendments to FE, roll out db.

Always follow the design cycle. It's a vicious cycle really

You also need to think about the 80/20 rule. Don't spend 80% of your time trying to complete 20% of the work. You will find out that your effort into completing one small task can outweigh the problem and as such it becomes unproductive.

I usually prepare a systems specification prior to completion, and have three main subject areas.

Technical Specification

Can it actually be written? Is Access caperble of doing what you want it to do without and third party inclusion/intervention?

Financial Specification

Can the client actually afford it? Does the cost of the application justify is creation in the first instance.

Social Specification

Will the end users use it? I have written a few programs, especially for the NHS, where the idea has been spawned by the Manager/Budget Holder. You then go away and write the app. Then the intended end users, who most likely have never ben informed about it, pull it to bits and refuse to use it.

Once you get past this stage then the likelyhood of major re writes is minimised completely.

DCrake said:

Then the intended end users, who most likely have never ben informed about it, pull it to bits and refuse to use it.

Click to expand...

Really? But you still get paid for it?

That may be the case sometimes, however the system specification is written before you commence writing the program and is presented to the client with the fee for the report. This fee is then included into the cost of the application.

Remember you could spend ages writing a system spec, giving it to the client, who then gives backword on the app. Unknown to you if then touts your spec elsewhere to get a better price. They will think differently when you tell them it costs £600 for the spec.

By speaking to intended end users about the intended app not only opens their eyes to wht is happening but also gives you a window into the background of the project requirements. Get them on your side and you are well on your way.

vbaInet said:

Really? But you still get paid for it?

Click to expand...

Maybe NOT.

I know of in-house developers that may have got paid, but ultimately lost their job because of this.

If you are a contractor, it is possible to not get paid in full.

Even worse is that you end up getting a bad reputation/referral.

HiTechCoach said:

Maybe NOT.

I know of in-house developers that may have got paid, but ultimately lost their job because of this.

If you are a contractor, it is possible to not get paid in full.

Even worse is that you end up getting a bad reputation/referral.

Click to expand...

I always ensure I get my full pay based on the contract signed