Even with modern software methodologies - we still have problems producing code that meets the customers' needs. Part of this is due to traditional requirements problems, but many problems can be traced to errors that crop up during the actual software development.

In my presentation, I will discuss how programming languages fit into the overall "quality" recipe. In addition, I will show how languages have evolved, and what qualities are necessary for a language to be considered "part of the solution" rather than "part of the problem".

The focus of my presentation will not be a traditional "Wow - here's my favorite programming language" - but emphasize features necessary for developing long-life reliable embedded code. While many languages are currently being used to develop this type of code - many of the languages are actually contributing to the problem. Features necessary to build reliable code will be discussed, along with various language paradigms that separate "solution" languages from "problem" languages.

David A. Cook is the Principal Engineering Consultant, Shim Enterprises, Inc., and is currently working as a software engineering consultant to the Software Technology Support Center at Hill AFB, Utah. David has over 30 years experience in software development and software management. He was formerly an associate professor of computer science at the U. S. Air Force Academy (where he was also the department research director), and also a former deputy department head of the Software Professional Development Program at the Air Force Institute of Technology. He has published numerous articles on software process improvement, software engineering, object-oriented software development, programming languages, configuration management, and requirements engineering. He has a Ph.D. in computer science from Texas A&M University, and is an authorized Personal Software Process (PSP) instructor.

NOTE: At the meeting David Cook offered to send a copy of his slides to anyone who requested them by email. He gave his Email Address as david.cook@hill.af.mil.

The program was "Why we have problems producing quality code-and why a good programming language is part of the solution, not part of the problem", presented by Dr. David A. Cook of Shim Enterprises. This was a joint meeting of the Los Angeles Chapter of ACM, SIGADA, and SIGPLAN.

Hal Hart introduced Dave Cook as a prolific speaker on software engineering topics and mentioned that he was the organizer of the tutorials at several SIGAda conferences.

Dave presented a slide that said he would cover language history, topologies of languages, the effects of languages on coding and how to use code to improve quality. The primary goal should be "Keep the customer satisfied". We've tried language after language. How many languages? Over 2,000. Dave presented a number of slides with a long list of languages, too many to count. Why so many? Languages give us power over the hardware. Languages have developed in certain phases corresponding to the capabilities of the hardware and the compilers available. Generations of languages? Cobol and Fortran are 1st generation languages unless you count machine code and assembler as 1st in which case they are 2nd. What about Object oriented Cobol 2000? Pick your favorite generation number.

A better way to categorize languages is look at the capabilities and limitation each "type" of language offers. He views these "types" as topologies, the shape of the language. Early machine and assembly languages made no distinction between program and data, the program was a collection of data and code, freely intermixed. You could multiply numbers by instructions and get workable results. However, these programs were hard to write and difficult to maintain.

During the 50s and 60s Cobol and Fortran provided separation between program and data. Later languages in the 70s and 80's with improved versions of Cobol and Fortran, Algol, PL/1, Pascal, C still used global data and provided no way to enforce abstractions.

The topology of modern languages includes C++, Ada, Ada 95 and Java. Finally, enforcement of abstractions. They provide controlled access to data and subprograms, hidden data and subprograms, protected types and objects, and automatic operations. The bad news is that a language is just a tool used to solve a problem. Languages force limitations on the way we think. We need to focus on the problem, not the solution. We have combinations of easy and complex problems and solutions. Students frequently provide complex solutions to easy problems and part of their training is to solve easy problems simply. Unfortunately there are no easy problems in the real world and usually complex problems require complex solutions.

A new way to view languages is as tools or abstractions to help us solve problems. Early machine language was so machine-oriented most effort was focused on understanding the computer, not the problem. Assembler languages were an improvement. Early compiled languages (Cobol and Fortran) were somewhat machine independent. This was important, programmers were no longer tied to one particular machine and the machine became an abstraction so more time could be spent understanding the problem rather than the hardware. Modern languages implement abstractions (such things as arrays, records, stacks and queues). Object-oriented programming languages (C++, Ada 95 and Java) allow thinking of real-world objects from within the language.

To facilitate long term maintenance a language should be understandable to the developer, the maintainer and must be understandable enough to allow requirements traceability, and verification and validation. The more complex a language, the steeper the learning curve. Modern languages allow focusing on the problem instead of how to implement the solution. However, the barrier between understanding the users problem and solving it still remains because we have an incorrect view of software where we determine the real world problem and [sic, the] code the solution. In the real world there are many interactions and inputs during an iterative process of solving the problem. We need to write code that is reliable, understandable, modifiable, and efficient.

Dave said that in the early 1960's we were told "Flow chart before you code'. In the late 1960's "Flow charts are archaic. Use a language that is self-documenting". Early 1970's, "Languages are confusing, use a PDL to design". Mid 1970's "PDL's are obsolete, Top down design will work". 1980's "Top down design is insufficient, try structured analysis & structured design. 1990 "SASD is obsolete. Use object-oriented methodologies". 2000's "OO methods are insufficient, use the unified modeling language". UML supports activity diagrams, which means "Flow chart before you code". Apparently software development has gone through a complete cycle.

Our tasks are getting more complex and we know what to do, we just don't do it. We need a way to bridge requirements to design that forces us to create understandable systems. Complex requirements require complex code. If you can't understand the code you probably can't test or maintain it.

Classic mistakes are expecting a silver bullet, overestimating saving for tool introduction, changing tools in the middle of a program and poor or no configuration control.

You can plan all you want but it is still going take some minimum development time. No amount of planning can shorten the time below some constant, but improper planning and preparation lengthen the time considerably. 75% of failures are in integration testing. Review (both peer and desk check) and don't rely only upon a testing team. Why don't we read the code? Most code is not easy to either read or review.

Another item-Are your developers really developers? There is a declining pool of programmers, developers, and software engineers so we are using people with other backgrounds to fill those slots. This is not necessarily a bad thing. The problem is that almost anyone coming out of high school or college thinks they know how to develop code but lack fundamental skills and knowledge we used to take for granted in developers.

We need to get back to basics. Developers need the basic training and education we used to give to programmers, the "core" knowledge. Without it you get code that is not reliable or maintainable and that cannot be integrated. We get poor code because we write code that is not easily understood and today's "modern" development languages are not written to be understandable. Some development languages were designed to be self-documenting, but C, C++, and Java are definitely not. Ada is a good language. We need a coding standard that forces developers to use meaningful names, requires documentation and a header, and establishes other conventions. Developers should understand coupling, cohesion, variable scope and data structures. Coupling measures relationships among modules and cohesion measures relatedness within a module. Examples were provided for acceptable and unacceptable coupling and cohesion.

Minimize the scope of a variable, use data structures and declare all variable types. Object oriented languages work. You want your tools to interface with the language and you want to force early interface and error checking. Languages should not perform dangerous actions such as type conversions and parameter mismatches and ignoring return values.

Finally, use a language that forces designers and developers to focus on interfaces early, checks interfaces prior to compiling and linking, allows easy abstraction and enforces the abstraction. Dave recommended the book Code Complete by Steve McConnell (Microsoft Press). For a good source of software engineering information do a search on "Crosstalk" that will lead you to Crosstalk - The Journal of Defense Software Engineering.

David Cook can be reached at david.cook@hill.af.mil for additional information or for copies of the slides he used in his presentation. Telephone: (801) 775-3055 or DSN 775-3055.

This was an excellent presentation with a great deal of very practical information about languages and software development. His presentation was interesting and easy to follow, and he used humor to spice up his talk. You had to be there to really get the benefit as he covered much more than presented in this article.

This was the tenth and last meeting of the LA Chapter year and was attended by about 23 persons.
Mike Walsh, LA ACM Secretary