Youry's Blog

Youry's Blog

In memory of Lary Bernstein. “Retrospective of Lawrence Bernstein”, NJIT Software Engineering

leave a comment »

Larry died peacefully at home on Friday November 2, 2012 according to his wishes.

I knew him for several months only (maybe a half of year), last his months, but I was so glad to discuss with him about SW Engineering problems and about SW Engineering teaching at post secondary institutions.

Before his death he sent email to about 70 people with his MyRetro on 20 October 2012. He had cancer. I think I can publish his message on my blog, especially because in the past I already asked his permission to publish our discussions on my blog for my and only for my students and SW Engineers. I think he would be happy to see, that his ideas and his thoughts can be used by other SW Engineers and Computer Scientist even after his death.

May he rest in peace!

Lawrence Bernstein
NJIT Software Engineering adjunct Professor
20 October 2012

I retired after 35 years at Bell Laboratories. I had great jobs there. Where else could a kid come out of Rensselaer Polytechnic Institute with an E.E. degree at the very beginning of the computer revolution and have the opportunity to shape that development?
The summer before my senior year at RPI, I wrote my first program. I had a summer job testing circuit boards for sonar systems. I found a computer closeted away and used it to write a program to compute settings for active sonar systems. I was so proud! It reduced two weeks of design work to 15 minutes. My colleagues were less than thrilled. They tsked over my foolishness in trusting such an unproven thing and went back to their manual design methods. Early Lesson #1: Follow your bliss.
Undeterred by the discouraging words, the following June found me graduated and working at Bell Labs, writing software for an antimissile system. My job was to understand the system design and translate it into a set of specifications for programming warhead detection software. This accidentally provided an early lesson in configuration management.
Sequentially numbered punched cards were used to create test data and, though we passed a software incentive fee test for the project, we did not get consistent results. The culprit was human error. What I thought were 40 cards cycled 1,000 times were actually only 39 cards. The computer center clerk had dropped the deck and never checked that the card order–and number of cards!–was correct before creating the driver magnetic tape. Early Lesson #2: People can confound the best laid plans.
NASA recognized the need for formal configuration management as part of the Apollo program. Their approach of manual punched card manipulation became the foundation for the development of the Source Card Control automated system that was the grandfather of today’s configuration control software tool industry.
The army customer next decided that a system to intercept many warheads in one engagement was critical. Redesign work had to include parallel processing with shared memory and up to ten processors. The National Academy of Sciences opined that such a system could never work. Early Lesson #3: Don’t be discouraged by anything you hear, but listen carefully. You might get a pearl.
My job was to design a task assignment system that spread the work load, honored precedence relations, and met the tight response time requirements of this real-time system. Our design worked, but my colleagues and I considered all suggestions and made special provision to dedicate several processors to battle planning software.
About this time, I realized the wisdom of the magic words, “What changed?” The response is usually “NOTHING,” delivered defensively. Calm insistence on reviewing the configuration often reveals a change deemed harmless to be the culprit. One time we wrote and debugged software to transmit 24 reels of tape containing radar data from a Pacific Ocean island to the east coast of the United States in 36 hours so that Lincoln Labs could determine if solar panels for the Sky Lab had properly deployed. They hadn’t. Early Lesson #4: Check and verify, again and again.
After a series of mostly successful tests on the Pacific Missile Range and the signing of the SALT II anti-missile treaty, I turned my attention to the Bell Telephone companies in the United States. Software was still the poor cousin of the industry. There was little respect for this mysterious stuff that seemed so irritable, so unknowable and yet so critical to the business. This lack of management vision caused a great many young people to be trained in software design and then let go, often to make brilliant careers elsewhere.
I became a software project manager in 1975 for a project called BISCOM that was in a shambles. When the car service drivers for the customers’ executives knew the daily status of BISCOM, things were really bad.
I had many problems to confront. I could not estimate how many people would be needed to create a given set of features or just how long it would take to produce a fully tested release. Too often I found myself explaining what went wrong rather than fixing problems. Fairly soon, though, some solid ground developed.
The relationship between developer and customer is fundamental to success, and prototyping is an excellent method for establishing mutual understanding. I found that teamwork would actually double productivity. It is difficult in the present day to remember just how difficult it was to explain and imagine methods that were essentially invisible to users who had always before had tangible “stuff” to handle.
One executive asked several accomplished software engineers to examine the project and its people. They reported, “Most of the developers have mathematics/computer science backgrounds. Although it is important to have developers with a good understanding of current software tools, it is at least equally as important to have people with sound engineering backgrounds. The mathematician and the engineer each bring to a task different and complementary viewpoints and one rarely finds individuals who can successfully represent both. Future hiring should be of candidates with engineering backgrounds until a better computer science/engineer balance is achieved.”
Was this carefully and dispassionately received by the 1975 BISCOM project management in the spirit in which it was offered? Hardly! “This recommendation is only partially accepted. Although we agree that people must grow to do software engineering and sophisticated design jobs, we do not accept the notion that an engineering background is necessary to achieve these goals.” The engineer vs. computer scientist issue caused the organization to discount the entire audit report but the notion of prototyping was quickly accepted. Early Lesson # 5: Prototype to understand the requirements.
It was the first time I encountered the Computer Science vs. Software Engineering turf battle. Unfortunately, it continues to this day with computer scientists arbitrarily calling themselves engineers, though without the necessary study for the degree.
The computer scientist is needed to produce the working software so that it performs needed features in a trustworthy manner. The software engineer packages the software into a system, solves problems, simplifies high level algorithms, estimates costs and schedules, models system reliability, models the economic value of the projected system and creates architecture and high level interface designs.
This conflict will remain unresolved until liability for failure is assigned to individuals as well as corporations.


1. Start small, 10 to 20% of the ultimate staff, to understand the customer requirements, build a prototype and create a first order architecture. When there are more people available, assign them to learning new technology or the application domain while the high level architecture team performs exploratory development tasks.

2. Cultivate a friendly user site so that the customer’s people feel ownership in the project and help the developers understand what is really needed and meant by the abstract requirements.

3. Hire the best people you can afford, and steer the best of the best to the application. Simplify the product design and algorithms. Design simplification through reuse and redesign works well. Schedule and hold periodic project meetings with a fixed agenda.

4. Invite the customer’s people to offer solutions, but ask your own software engineers to develop THE solution.

5. Create a configuration management organization to maintain the official project libraries, do builds and track changes. This activity is variously called “software manufacturing” or “software administration.”

1. Metrics based on lines of code are useless and misleading. Tracking metrics for the sake of having metrics leads to a false sense of management control. For example, I found that the reported number of customer high severity problems, even when the same problem was counted multiple times because it was reported from different installations, was a far better measure than correction reports per thousand lines of source code to measure software product quality and to direct bug fixing efforts.
2. Separating responsibility, accountability, authority and control often leads to chaos and interminable committee work.
3. Taking a one-size fits all approach and expecting the same processes to fit projects of all sizes is a mistake.
4. Insisting on specific software development processes before the project is defined, staffed or organized. The process must fit the problem.
5. Not having assigned people to tool development as the best programmers will migrate from the application to making tools.

After retiring from Bell Labs, I went on to teach at Stevens Institute of Technology and created their Software Engineering Master’s Program. Then I had the opportunity to teach software engineering topics for three years at New Jersey Institute of Technology.
I had a very exciting fifty years helping the software industry grow. It is a shame that we still can not agree that there is a serious and important difference between the computer scientist and the software engineer. Both are needed and both bring special skills and knowledge to building software systems.
Too many in our profession do not read our rich literature. I expected professionals who want me to respect them as software engineers to have studied or at least be familiar with these ten publications:
1. Fred Brooks, The Mythical Man-Month, Anniversary Edition, Fred P. Brooks, Addison-Wesley, 1995, ISBN-10 0-20183595-9
2. D.L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules,” Communications of the ACM, Vol. 15, No. 12, Dec. 1972, pp. 1053-1058.
3. B.W. Boehm, “Software Engineering,” IEEE Transactions on Computers, Vol. C-25, No. 12 Dec 1976, pp. 1226-1241 and Software Engineering Economics, Prentice-Hall, 1981, ISBN 0-13-822122-7
5. Albert Endres and Dieter Rombach, A Handbook of Software and Systems Engineering, Pearson Addison-Wesley, 2003, ISBN 0-321-15420-7.
6. Peter G. Neumann, Computer Related Risks, Addison-Wesley, 1995, ISBN 0-201-55805-X.
7. Tom DeMarco & Timothy Lister, Peopleware 2nd ed., Dorset House, 1999, ISBN 0-932633-43-9
8. Martin Fowler, Refactoring Improving the Design of Existing Code, Addison-Wesley, 1999, ISBN 0=2201-4567-2.
9. Hans Van Vliet, Software Engineering Principles and Practice 2nd edition, Wiley, 2000, ISBN 0-471-97508-7.
10. Lawrence Bernstein and C.M. Yuhas, Trustworthy Systems through Quantitative Software Engineering, Wiley, 2005, ISBN 0-471-69691-9


Written by youryblog

November 6, 2012 at 11:04 PM

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: