Sufficient architecture
"No, not yet." He replied, "I am trying to get the DB right first, then I will get onto writing the application". I asked what he meant by getting the DB right. He explained that he wanted to make this the best video-hire software ever, and that I should hear about some of the features that are going into it as a result of the DB structure he has made.
- Record the cast of the film.
- Record the director, producer etc.
- Record the genre; horror, comedy, etc.
- Record film information for films due to be released in the future.
All sorts of stuff. His idea was that he could analyse rental history and match up upcoming releases with people who might be interested in them. Then the computer could do a mailshot to the relevant people, enticing them to come back and rent out a film or two.
"Great ideas!" I said, "but.....Can members rent out films?"
"No, " he replied, "I haven't done that bit yet!"
This is the message I always try to get across when I am helping to design a new system. I either meet people who want their app to be a Swiss army knife application (who inevitably deliver late, and deliver rubbish) or those who want to write any old rubbish to get the job done and get it out of the door (which inevitably falls apart whenever a change is required). Someone once actually said to me "The problem with doing things properly is that it takes too long!".
Anyway, I read someone else's post on this subject this morning and just wanted to say
Don't go designing apps with features nobody has asked for, if there is something the customer wants in the future they are quick enough to ask for it, and if they really want it they will pay for it too!
Comments
It's a thin line and hard to point it down between what's needed now or tomorrow.
Many times specs are not completed and you need to write code keeping in mind things might change.
You are forced to do more work then it's needed to anticipate changes.