Lecture 01 Notes - The Science of the Happy Ending

The first lecture has come and gone. After some housekeeping we moved on to consider programming. I regard it as: The Science of the Happy Ending A project should end with you, the programmer, walking away with a wad of cash which is fair reward for effort and the customer with a system that does what they want. To this end the program itself is just a small part of the job that you need to do. You must also do things like:

• Make sure the customer is prepared (and able) to pay you a good rate for the job.
• Make sure that you understand what the problem is (sometimes the customer doesn't even know this one).
• Make sure that you don't do more work than you need. And you get paid for what you do.
• Make sure that you deliver a product which does the job, can be proved to do the job, and can be maintained over time.

Learning C# is not going to answer all the above points, but it does make a good tool to do the program part. I'm sorry if it seems I'm taking an unduly "product centered" view of the art of programming. But I find that this helps a lot when considering what you should be doing. This part of the course will concentrate on the programming part of the effort. Other parts will worry about specification, testing and the other issues. But you should always keep a clear view of that mythical "happy ending" in whatever you do.

In terms of the business of programming itself, it is worth considering a few terms:

metadata - data about data. Saying "we store the age" is one thing. Saying "we store the age as an integer in years with a low limit of 0 years and an upper limit of 120 years" is much more sensible. The long bit is the data about the data. Or metadata.

abstraction - stepping back from the problem. Before you worry about precisely how the "customer" item will work internally you need to consider just what the customer item will be called upon to do. You can say things like "the customer has an address" and then later you go back and fill in the detail. You need to practice abstraction. Write a program to keep track of a dress shop (and we might do this) and you might think that your starting point is "Dress". It is not. It is "StockItem". If our dress shop starts selling handbags we need a way to handle these later. If we start at the level of dress we are heading for trouble. Start with StockItem and every thing that we want to sell can be handled like this.

program - a sequence of steps which tells something how to do something. This is one way of viewing programming. There are others. We are using this view because we have found it the easiest for people to learn. With this in mind consider:

• shopping list
• address book
• chocolate cake recipe
• CD track list
• club member list

One of these is a program. One of these might be a program. The recipe is the obvious one. It is a sequence of steps. The others are simply collections. Except that when I go shopping I get instructions like "..if you can't get self raising flour then get plain. But then you have to buy some baking powder..." which sound like instructions to me.