A recipe for disaster? Part 2 - Press-Republican: Columns

A recipe for disaster? Part 2

Print
Font Size:
Default font size
Larger font size

Posted: Sunday, June 8, 2014 3:24 am

Last month I expressed my concerns with the current trend of recruiting young folks, especially women, to be trained to write programs so they would have a useful trade with which to enter the world of Work.

I mentioned that while I have nothing against teaching anybody the art and craft of programming (in fact, I believe it fosters creativity, confidence and perseverance), I do worry that these short training courses have the potential to do more harm than good.

Why would I think such a thing?

Because, as the old saying goes, “A little learning can be a dangerous thing.”

Writing a single short program to do a simple application is a creative, rewarding and relatively straightforward process. But the creation of real-world software is no longer a simple proposition; it requires a well-oiled team of individuals writing code that works well together.

While it is possible to teach team skills to novices, it is very, very difficult (near impossible, I think) to teach one how to write programs that are correct, efficient and reliable.

To be correct, the program must represent an accurate solution to a problem, and this is the most difficult and important part of the problem-solving process.

In many cases we can end up with a solution to an entirely different problem than the one we wished to solve or other unintended side effects.

For example, suppose the problem is to keep food from spoiling, then one solution is to design and implement a refrigerator. I begin by identifying a list of requirements or specifications for the fridge; e.g. “The finished product should be capable of cooling food down from temperature X to, say, temperature X-32 in Y minutes” and a host of others concerning power, efficiency, size, weight, etc.

But no matter how hard I try, I cannot write a complete set of specs (if I could I would have to include unlikely ones such as: “When the user opens the door the food should not fly out of the fridge.” The best I can hope for is the final implementation adheres to my set of incomplete specifications.

To be efficient, a programmer must be able to break a large complex problem down into smaller simpler pieces, and thus by solving each part, the whole problem gets solved. (I can’t eat an apple in one bite, but many small bites will do the job.) But that is not enough for a well-designed computer program; for that we must add the requirement that each of the parts be modular.

By “modular” we mean that an executing module does not influence the execution of any of the hundreds (possibly thousands) of other modules comprising the total system. This helps to insure that if we have a group of modules working together to perform a task, we don’t have to test their interactions because truly there will be none.

For example, you expect your car to be a modular system — when you change the oil, you don’t anticipate all four tires to go flat. There are many advantages to modular programs: different members of the programming team can work concurrently on separate modules resulting in a finished product sooner. Also, modules are easy to test, debug and modify (without unintended side effects).

To be reliable, a program must comprise modules that correctly execute singly and in combination with all of the possible environments they run in. With most software this environment is provided by you, the user.

Again, there is only a finite number of ways users can respond, but that finite number is usually so large that it might as well be infinite. For those with small children: how many times has your child completely frozen your computer as a result of randomly pressing keys?

All of the above explanation is meant to show how difficult it is to write software. All comprehensive computer science programs require one or more high-level courses in software engineering where the above issues are addressed

My concern is that, in the haste to provide well-paying jobs for young people, we may create many more problems than we can solve. And while job creation is certainly a good thing, we should keep in mind that the purpose of education is not just to make a living, but to live a life.

Dr. Stewart A. Denenberg is an emeritus professor of computer science at Plattsburgh State, retiring recently after 30 years there. Before that, he worked as a technical writer, programmer and consultant to the U.S. Navy and private Industry. Send comments and suggestions to his blog at www.tec-soc.blogspot.com, where there is additional text and links. He can also be reached at denenbsa@gmail.com.

 

 

 

 

coupons
ADVERTISERS


Click on photo to view gallery with latest photos