Larry Bernstein

Trustworthy software systems

Much software engineering focuses on cost and schedule, especially schedule. This talk will describe how a shift is needed. The software engineer must make judgments or tradeoffs among the features the software provides, the time it will take to produce the software, the cost of producing the software, how easy it is to use and how reliable it is. Not only must software designers consider how the software will perform – they must account for consequences of failures.

Things i learned from taming software development

ON SYSTEMS and SOFTWARE ENGINEERS A good specification greatly improves programmer productivity. Understanding the customer requirements early and correctly reduces project risk. Too often this step is ignored. When you must build unplanned features into a system on-the-fly you often introduce severe schedule delays. For complex systems, use joint teams of experienced system and software engineers to identify the subsystems which comprise the highest level of software decomposition. Both system and software engineers input their expertise into this effort, produce a prototype and agree on a design at this level. Once agreement is reached the system engineers can detail their requirements in terms of those agreed upon modules and the software types can engineer the lower levels of the decomposition. This approach has the benefit of increasing the mutual understanding of the problem to be solved by forcing joint design. Software oriented folks must be engaged as requirements are written. Unfortunately this is not often done. Software features, economics, reliability and performance need to be modeled and managed. . Feature requirements not validated with regard to performance often results in products that are not maintainable. Jackson

Software engineering design principles for ultra-large-scale systems

The most important property of an ultra-large system is its huge size on any measured dimension. Scale changes everything. These principles were quite effective when I led the development of Bell Labs projects that employed at least 50 or more people for at least 12 to 48 months. Several projects became product lines; one was deployed in 300 sites and another saved the US Telephone industry

Managing computer suppliers

1B dollars a year in operations costs. Many are of these principles are well known but not well practiced. Some of the resulting products were spun off as new companies and these design principles were used even as the companies evolved to new products or new markets.

Cross avoid shelf-ware by making your systems easy-to-use

One of the challenges I had as a software application project manager at Bell Labs was the responsibility to manage computer suppliers so that equipment and support was ready when we needed them at telephone company IT centers. There were seven computer suppliers I dealt with on three major projects. Each supplier became an intimate member of its project team and I participated in the deployment of hundreds of their computers to serve the needs of the then Bell System. Here is how I did it. The largest deployment was about 500 PDP 11/70s from the long gone Digital Equipment Corporation. The technical interface focused on having a single person who was the designated interface for the supplier to me. This person had to be technically competent and know the suppliers machines and organization. The interface person had to get things done, expedite installations and escalate problems. In critical situations, we needed to communicate with their technical people directly and without the need for translation. A pure marketing type was unacceptable. Lets call this contact the suppliers program manager for my project, who was responsible for coordination of our software needs, our hardware needs and deployment plans, product requirements , deployment plans, field maintenance and for keeping me and my people well informed of their corporate directions. For example when DEC shifted to the VAX computer line they refused to make UNIX a standard supported operating system but were willing to establish a focused and specialized organization to serve our requirements. Finding this unacceptable, I declared that the VAX was not a continuation of the PDP 11/70 computer line and we went out for a new bid for continued deployment of our application. We selected a competitor, who offered the HP-UX system as a standard supported operating system and the rest is history. We undertook the porting of our applications to the HP-UX operating system and HP invested multi-millions to meet our technical needs. We also encouraged Amdahl to provide UNIX operating environments, which they did to great effect. It was very important for me, as a Bell Labs manager to meet with suppliers executives to confirm their commitment and funding to our project and for them to understand our expectations and our assessment of the performances of their project manager. The principle that even though the program manager did not have all the resources for our support …

Eternal software engineering questions

A well-made tool is a joy, whether it is the perfectly shaped flint carver of a Stone Age ancestor or the information network of a 21st century software engineer. The discipline that studies human capabilities and applies this knowledge to product and services design goes by many names–human factors, ergonomics, user interface design, user friendliness–but there is no doubt about its importance in the computer industry today. In 1973 I saw a framed mantra in a Japanese toy store that read “Usability equals beauty” and found that architectures that embody this mantra makes us users happy. Unfortunately we live in a world that rubs us raw with complexity, speed and information overdoses. Human factors design can make life pleasant or agonizingly frustrating. Expert software architects know how to engineer systems so that they are “transparent” in use and they understand that the future demands even more effort to make increasingly complex systems and systems-of-systems usable and acceptable. Good human factors design helps to overcome the resistance to change that every new system brings. Human factors engineering is integral to every step of the design process. It is not a matter of pretty packaging at the end of the production line, nor a bag of tricks for circumventing some other design flaw. It might be helpful to examine the kind of things that a human factors audit can reveal. AT&T conducted an audit to evaluate human factors engineering issues at its Network Operations Center in Bedminster, New Jersey. The AT&T network is an incredibly complex combination of hardware, software and people. Data from many geographically dispersed sources are brought together and monitored in the Network Operations Center. A wallboard display serves an important surveillance function, allowing the network manager to integrate information from a variety of sources and determine what else should be retrieved to isolate problems. The wallboard eases congestion on the floor of the center because its displays are generated from terminals in other locations. Although this system did a good job and got rave reviews from the workers, there was room for improvement. The first recommendation was to minimize terminal clutter by replacing multiple terminals with new workstations that supported multi-window graphics displays. This saved the

Eternal software engineering cross feature/architecture design simplifications

Why cant software people say what they can do and do what they say? Why is it so hard to define the content, assure the quality, and document the accuracy? What kind of professional people cannot say what they can deliver, when they can deliver it, and how much it will cost? The frustration is real, but the answers are complex and confounded by subtle interactions that, if unexamined and left unmanaged, lead to blame, recriminations, cost overruns, and dissatisfied customers. The underlying uncertainties pervading the people, product, process and project are the causes. The key to achieving sanity lies in the authority of the project manager (PM). The PM must be experienced in successful projects and be technically competent. The size of the projects in the PMs experience should be similar to or somewhat smaller than the project under consideration. Technical people must make technical decisions, matching individual talents to tasks, and arrive at points of closure. Where technical people can do this, the highly talented rush to join the team. The PM achieves this state by establishing appropriate ground rules and conditions. First, the PM is the only one to make commitments. Second, these commitments are based on decisions that are data-driven. Third, the PM maintains collegial professional relationships with superiors and clients who recognize the PMs appropriate authority to act in a timely way. Fourth, those superiors protect the authority of the PM. — Larry Bernstein

Characterizing people as non-linear, first-order components in software development, is written by Alistair A.R. Cockburn and published in Humans and Technology, HaT Technical Report 1999.03, Oct 21, 1999.

Software architecture techniques can let us focus on the dynamic behavior of a software system so that we might achieve needed dependability. It is too bad that we emphasize features over structure and think about the execution stricture of a system when we have a problem. This series of articles crosses the boundary between features and structures with the understanding that design simplification will make a software system more reliable and make it possible to avoid some known problems. Most current software theory focuses on its static behavior by analyzing source listings. There is little theory on its dynamic behavior and its performance under load. Often we do not know what load to expect. Dr. Vinton Cerf, inventor of the INTERNET, has remarked that applications have no idea of what they will need in network resources when they are installed. As a result, we try to avoid serious software problems by over-engineering and over-testing. Software engineers cannot ensure that a small change in software will produce only a small change in system performance. A ruthless attention to boundary engineering helps constrain the execution domain of the product. Industry practice is to test and retest every time any change is made in the hope of catching the unforeseen consequences of the tinkering. The April 25, 1994 issue of Forbes Magazine pointed out that a three-line change to a 2-million line program caused multiple failures due to a single fault. There is a lesson here, namely that it is software failures, not faults that need to be measured. Design constraints that can help software stability need to be codified before we can hope to deliver reliable performance. Professional software architects account for non-feature functions that prevent the occurrence of well-known anomalies. Here begins a collection of reasonable constraints that make software systems better able to be understood. Your software shop should practice them. The first cross feature/ structure deals with the scaling problem inherent in tracking the status of long lists of work items. This is often part of the class of software called work management. If there are just a few work items the order of processing is inconsequential; but, as the number of items increases the way the needed feature is implemented becomes critical to system performance. The feature/architecture technique we call update by exception Define a list of work items. Each one requires an indication …

Pithy software engineering quotes new column

This is a seminal article recently cited at an Agility seminar in New York. It is a must read by all software people and those who pay their salaries. Cockburns approach is humanistic and it works! The non-linear behavior by the people component fits well with my experience and as an engineer I know we need tight feedback control to prevent a nonlinear system from becoming unstable. I put in place technicians and expediters as interfaces between developers and testers. Then I set up an extensive libraries and code analysis tools run by the technicians who I called software manufacturers. They built our systems, control the change process and maintained the build and the test machines. They were in-line and not support. They made all deliverables to clients. These people prided themselves in knowing what version was working where and that the agreed to standards of code structure were followed. Managers were asked to adjudicate disagreements and manage by exception; not to make all decisions. Middle managers are a problem. They fight hiring people better than them, new processes and new technologies. They are on the hook for delivery and become more conservative as things go badly. Success is difficult to measure. To me it is the ability to solve the customers problem even when they do not understand it themselves. The trust and loyalty of the customer is the measure of success; but only if you are profitable. In any human endeavor, good managers are critical. In software projects they are critical. You cannot replace bad managers with good processes and you cannot automate a chaotic process. Expert project managers learned all this by the school of hard knocks. We need to teach this common experience so that we do not continue to repeat mistakes and yet expect different results. Cockburn declares the end of software engineering. I disagree. It is too bad that software engineering has become to mean software process engineering. Making technical trade-offs about the characteristics of a product and dealing with non-feature functions such as having the appropriate reliability, security and safety are all software engineering questions that need more attention. The software engineer must know how to improve system availability by an order of magnitude or make sure that the software system is robust to buffer overflows and memory leaks. Consider the merging need for Green Software solutions. Do you know how to design …

Subject: Taking Software Requirements from Hearsay to Analysis

A speaker frame is constructed from dried paper pulp. Features in the speaker frame such as holes or slits are formed by carbonizing corresponding sections in the dried paper pulp and applying shear processing to remove the carbonized material. A carbonizing mold contains protrusions corresponding to the sections in the dried pulp to be carbonized. The result is a high quality speaker frame that is biodegradable and can be produced economically.