The most basic principle is the one with which software engineering began, i.e. the idea that you can solve a particular problem by performing a sequence of steps. Computers owe their very existence to the fact that they can do this incredibly quickly.

Some programmers never really get beyond this. Others go so far beyond it that they need to be reminded (occasionally ) that the most elegant solution to a problem may well be a simple sequence of steps, declarative/functional programming notwithstanding.

Hot on the heels of the processing concept came the various flow of control programming directives (if-then-else, while-do, etc) including the infamous goto, which some programmers (me included) think is the worse thing in the world and others couldn't live without. Nothing very new has appeared since the introduction of exceptions, a concept still trying to find its feet between those who (like me) use them extremeley sparingly and others who think you should use them all the time (for the record, I use exceptions in abort situations and test-harnesses and rarely anywhere else).

Multi-tasking, which is where more than one process takes place in parallel (not necessarily on the same processor), has a strange relationship with software engineering. In many cases it isn't a software engineering issue at all, more a case of hardware configuration and software deployment. Multi-tasking becomes a software engineering issue when an engineer has to make the decisions on how to partition his software into asynchronous (i.e. independant) modules.

Although multi-tasking has been around for at least 25 years, it is relatively unexplored as an engineering technique. Separating functionality into asynchronous modules communicating to each other via pipes is easy enough, and occurs naturally at the boundaries between, say, an application and a print-spooler, or an application and an operating system (like Windows). Seaparating functionality at a fine grained level is also easy to do - i.e. everything talking to everything else in an asynchronous manner. It's not very efficient, though. The problem is finding the optimal middle ground between these two extremes, and this is totally dependent on what the program is actually doing. Where this partitioning happens, it tends to be done on the basis of module-cohesion - i.e. grouping together everything which is related in some fashion. Multi-tasking, however, is all about performance rather than elegance of design. Module-cohesion may not be a bad first attempt but something more intelligent is required here.

Well, single-task programming is hard enough without adding this particular complication - at least, for now.

It is also worth mentioning that multi-tasking makes a significant appearance in low level programming, where the behaviour of peripheral devices provides a natural multi-processing environmnent (and I include in this keyboards and mice). There is a little bit of technique here to do with polling-vs-interrupt, safe-areas, locks and semaphores which anyone involved in this type of work will have to be familiar with. Generally speaking the order of the day is to try to minimise any processing you do inside an interrupt (i.e. when you've stopped your main process in order to do something else). Failure to do this could land you getting into all sorts of horrible real-time bugs (been there, done that, have the scars to prove it ).

Richard

The Principles of Software Engineering: start next