Programming for beginners

The first time I started as a software engineering student at college, DOS was the operating system, Windows was in its infancy and the colleges didn’t teach us how to program in the windows environment.

Nowadays, RAD programming tools are everywhere.

Rapid Application Development has been around for ages and within seconds – well minutes, even the beginner can bash in some code, hit run and see a window with their efforts in. In some cases, it will actually do stuff too.

“Learn Delphi in fourteen days…” the book said and well, I did, but then I did have the benefit of having several years of college, university and work experience behind me, so I don’t know what it would be like for a true beginner to do the same.

Actually I do.

It would be like it was for me, but without someone in the form of a college lecturer and mates to ask questions of and in the case of Delphi, I was only actually learning a new language, not the principals of programming from the ground up.

My programming experience was to begin with, an idea and then a bunch of code – known as hacking.

I wrote a version of the Mah Jongg games in visual Basic in a very short space of time and whilst it worked, the randomising aspect was poorly thought out. Users – my friends at work, started to notice patterns emerging in the placement of the tiles, which meant I had to go back and start thinking about improvements.

Of course, I had no plan to refer to, no design as such and making improvements was like trying to pull a card out of a carefully erected house of cards – almost guaranteed to make it fall down.

And so it was. I changed one thing in the program and seemed unable to make it work again.

This was all due to the fact that I was convinced that I knew what I was doing and didn’t need a design. Had I used even a simple design in the first place, I may well have been able to make the improvements without causing the whole thing to fall over.

It is a vehicle to help provide the structure, identify procedures, functions, flags and all the other technical stuff that help make the program work. If you like, it helps you to put the bits in the right boxes. Then if something needs updating or changing, you know which boxes to look in and updates, upgrades or repairs, should occur without adversely affecting anything else.

An Analogy

For this, I’m going to use making a cup of instant coffee as an example.

• · Put coffee in mug
• · Boil water
• · Add to coffee in mug

Looks reasonable, doesn’t it, but then you know what’s coming don’t you?

It seems far too easy and you’d be right.

Putting the coffee in the mug might seem simple enough, but how much?

You fix that and through trial and error, you get the program to put just the right amount of coffee into the mug.

Boil water, but again how much. You’re ecologically friendly and again through trial and error, you get the program to put just enough for your coffee into the kettle and the constant you created to store this quantity is coffeeWater.

Add to coffee in mug; job done.

The program runs perfectly, making you the right coffee each time you hit the button.

Then you have a visitor.

You ask if they would like a coffee and find out that they like white coffee.

Now all of a sudden, there’s an extra step, one that you hadn’t bargained on. So you add that line to the code. This is fairly simple because, it’s something that can go in at the end, giving you the following:

• · Put coffee in mug
• · Boil water
• · Add to coffee in mug
• · Add milk

The first problem you come across is the fact that in order for it to make both of you coffee, you have to boil the kettle twice.

You need to adapt the program to account for that that too.

That’s simple enough. You add a box that you can increment for each extra cup of coffee you want it to make.

However, you find that doesn’t work as it makes you a full mug of coffee and does the same for your visitor, but leaves no room for the milk, which the first time it runs, causes the milk to overflow from the mug, so you have to adapt the program to account for that.

How do you do that?

Essentially, you have hacked this program together and have tweaked the code to allow for your taste in coffee, with no milk or sugar. Now suddenly, you need two recipes to make one black coffee and one white. It’s only the water quantities you need to change, but you arrived at the full mug quantity through trial and error and now you’re going to have to do it all over again to account for the milk.

You are sensible enough to rename the constants for the water levels which have now become blackCoffeeWater and whiteCoffeeWater and you were alert enough to spot the following:-

milkQuantity = blackCoffeeWater – white­CoffeeWater, so that was alright.

Trouble is it only knows how to put in the water at full cup quantities.

Now you have a rewrite to make it so that you can boil enough water for more than one cup, taking into account whether each cup is black or white.

You’d probably have thought of that in the design phase if you hadn’t been quite so hasty in trying to hack it together in the first place.

The above was an exercise in silliness, because it’s not really a program anyone would really want to put together unless they make vending machines and even then, the ingredients are most likely powdered anyhow, therefore making the recipes simpler.

Real programmes however run into millions of lines of code and simple hacked changes are unlikely in the extreme, but it hopefully gave you an idea of how easy it would be to tie yourself up with something that on the face of it was quite simple, but change a couple of things and all of a sudden, it doesn’t look so simple at all.

So design first and then start coding.

It’s a bit like engineers and joiners – measure twice and cut once.

It may seem like you’re doing an awful lot and getting nowhere, but then you will find that when you want come to code or add more features, it’ll be that much easier.

It really does save time in the end.