Motorola SES

My notes from the Motorola Software Engineering Symposium, June 17-1, 1998. This is the first I ever heard anyone use the word "dialoging."

Contents

Overview stuff

Motorola sees software as its future. There were maybe 25 academics from all over at one day of their SES. Motorola is seeking to improve university ties (and hire our graduates...)

M has made marked improvements in software process since 1990. Most divisions are at CMM Level 3, with one or two at Level 5. Re-organization in news -- counter is 1000 new jobs already this year, 1500 interns this summer.

2/3 of Motorola's expenditure is on software. 95% of products are controlled by software.

Divisions: automotive, components, computer, and energy; cellular networks and space sector; cellular subscriber group; land mobile products; a couple more (oops).

Corporate initiatives: 10x cycle time reduction (since 1992), not there yet, some talk about shooting for 100x; 5NINES system availability; senior executive program; total customer satisfaction (eg satellite down -- customers called M service center, although it wasn't there technical fault); Year 2000 initiatives -- eg CMM goals; software solutions, executive 5-ups. "How do we make money with software."

Corporate software organizations: software business council; software engineering technology steering committee -- five-year lookahead; Quality Council -- subgroup on software quality -- SEI initiative, metrics working group; Motorola University -- college of software engineering technology.

Types of software: Information technology; component support software; manufacturing software -- robotics, vision, production line process; product software -- embedded real-time, networking.

The shift from a "hardware company" to a "software company" required large cultural change, esp at management levels. Introduction of software methodologies at engineering levels. "Grass-roots" changes. Resistance to CMM by hotshot engineers/programmers.

Hardware-software codesign is being looked at, but no process in place.

Jon Kannegaard, VP of software products, Javasoft

Java in "Early reality" era. 70M seats (yeah, right, is this Navigator and Explorer?), 2M JDK1.1 downloads, 700k developers, 225k on JDC, 140+ licensees. Early use for Web animation supplanted by JavaScript and GIF animations. Java for "serious" logic. ISO submission approved 20 to 2.

Consumer device potential -- Motorola, Lucent, TCI, Nortel, TI, Alcatel, Nokia, Samsung etc. Smart card potential -- Schlumberger, First Union blah blah.

The compatibility test suite is the single largest piece of the Java "platform" (JFC is second).

Personal Java -- consumer products such as cell phones, settops, PDAs etc, Embedded Java for devices that don't need access to Web applets. 10-100s of k. Card Java -- smart cards etc. Replaced window system: JFC -> pAWT. JavaSoft is doing a WinCE port!

Java-based web-phones (screen phones). Java-based wireless smart phones.

Applets and servlets enable networked devices: access web content, access same net-based applications. eg different servlets provide interface to different mobile devices, to the back-end application they look the same.

New APIS: JavaAuto; Mobile NC spec; voice-over-IP, etc etc etc.

Imperatives: performance, stability, and time to market. Sun porting and tuning center. HotSpot. Focussed development and deployment: internalization and prioritized, functional enhancements.

Java started 20x lower than native applications. Now 6x slower them C (JDK1.1 with JIT). In 1998, Sun's JVM will be the fastest; in 1999, Java will be the highest-performing language. (!) HotSpot focuses aggressive optimizations on "hot spots." (From work done at Rice.)

"Personal and embedded Java are pervading the communications industries."

Motorola technology presentations

Two-way radio communications

Software in portable phones: DSP firmware -- voice, filtering, noise elimination, replace significant amount of RF hardware; radio service software; host firmware; automated testing.

Issues: real-time/embedded software; cycle time/productivity; legacy; mission-critical customers; data (as opposed to voice -- currently 90/10 voice/data, expecting 10/90 eventually). Keeping old functionality while adding new is critical (customer requirement).

Astro radios have 400kloc (600k ROM, 18-24k RAM), 68HC11 CPU running at 0.75 MHz (!) to keep power consumption low.

Where to go: migrate/evolve architecture to improve reuse/quality; automated testing (50% of development cycle); new methodologies -- embedded-friendly and legacy-friendly. Currently using structured methodology.

I asked about the Java connection: potential for dynamic (wireless) download of new functionality, but unlikely to happen in this market for some time because of current hardware architectures. More likely to occur soon on consumer-oriented products. She didn't answer my question about time frame.

Cellular communication

2.7 Gigabucks R&D (company-wide)

Automotive, components, computers, and energy

Auto-makers are customer. Products designed-in 3-5 years in advance; schedule slips unacceptable, defect unacceptable. Extreme cost sensitivity.

Powertrain, steering, windows lights, etc etc etc

Areas of focus: rapid prototypes; control system modeling and simulation; code generation for small processors -- "interested in getting out of the coding business"; automated testing (unit and system) -- 100% statement coverage, difficulties modeling test space because of complicated interactions of system inputs; performance modeling in real-time environments (RISC vs CISC); reusable architectures -- how do you build abstraction layers; wireless communications; system engineering/partitioning -- hardware-software trade-offs.

Telematics: information over wireless. First market is automotive. Services on demand.

Wireless "recalls."

Technology issues: end-to-end system architecture; security; comms bandwidth; software reliability -- compare with desktops!; cost-driven resource constraints; speech I/O -- continuous, speaker-independent, noisy environment.

Software in satellite communications

Iridium software: around 13 Mloc.

Incremental development. Initial plan in three phases: test software; first launch software; mission software. (Requires that software be developed to allow upload.) Enhanced plan has 5 or 6 phases, allows earlier delivery and I&T. Uses SEI Level 4, aiming for level 5.

Dave Luckham -- software architecture

Causal event modeling.

Built in Java, objects that model a particular fabrication line. Communicate via commercial middleware called TIB (Tipco information bus?). Run the system, and add event sniffer on TIB. Build causal relations between events and pass to computation manager.

Events are structured into a four-level hierarchy.

  1. Events on TIB itself. Broadcasts, reads etc.
  2. Point to point communication (middleware disappears). Extracted from level 1. Events are protocol events: req to set up machine, response to operator, create and move locks, etc.
  3. Aggregate protocols into sequences. For example, setup machine, maintain machine.
  4. Abstract machines out. Deal with job lots, factory yield, cycle times etc.

Uses Rapide event simulation and analysis tools.

Panel: the future of software engineering

Barry Boehm

Missed it.

Betty Cheng

Educator's responsibility to provide student with a toolkit for software engineering. Must be rich enough to carry them through future generations of technology. Requires solid CS and SE foundation, and exposure to leading edge technologies. The right balance is key -- foundations are not useful without hands-on experience.

Key SE concepts: emphasis on a systematic process; all aspects of requirements; validation and verification; maintenance. Startling how many organizations are at "Level 0."

Foundational topics: logic and general math; problem solving, data structures and algorithms; automata theory; systems; languages. Important to understand ramifications of decisions you are making.

Hands-on: foundations applied to real examples; spiral approach is most effective; individual competence is essential; group work is useful.

Capstone project: synthesis component, team projects, exposure to real constraints from industry, notion of "project ownership." Solicit non-critical-path projects, real (changing) requirements. Industry involvement raised success rate from 50-60% success rate to 100%.

David Lorge Parnas

SE as a discipline? Answer: no.

So what do we do? No shortcuts; strict standards -- we need to identify and codify a core body of knowledge. There is no painless path -- not "software engineer" is really a software engineer. Core body of knowledge must be fundamental -- relevant forever, or never relevant? Goal: design better software.

1967 -- engineers weren't interested (NATO), so most work was done in computer science. Now, both EE and CS want to teach SE -- but neither can do it alone.

We can no longer squeeze what we know about computing and programming into traditional engineering or CS programs. Is SE really a branch of engineering -- all legislation and accreditation mechanisms are in place. Also, SE requires knowledge that is not in computer science.

Is today's "software engineering" really engineering? Is the ICSE conference really SE? Is IEEE Trans. SE really SE? -- NO.

Is the use of engineering principles, sound science, and mathematics to develop products that affect the safety and well being of the public, engineering? -- YES.

Software engineers are not just good programmers. An engineer is responsible for producing products

What's not on his list: teams, schedules, estimate costs, project management. These are not unique to SE -- they are generic to engineering.

What is on his list: discrete math; real-time scheduling; problem decomposition, systematic abstraction, how to document requirements, how to design extendible reducible software systems, how to specify complex component interface. How do you know when you're done?? (Not the importance of, but how to.)

Software engineering is sick: no licensing standards; too much empty talk about process -- process without product standards are meaningless; vague terminology like architecture; too little engineering math; not identified core knowledge; still looking for easy answers; students still getting inadequate educations; researchers not attacking fundamental problems; still treating the symptoms not the cure.

"You can't teach people how to think. They never think the way they're taught to, and never stop when they're supposed to."

Michal Young

There is a distinction between software developer and users. But to achieve real gains, must raise the level of abstraction, which blurs the line between people who develop software and people who use software: now have infrastructure developers, domain developers, and users (but blurred). Domain experts lack tools and training for software engineering.

So: software engineers must become consultants to domain specialists -- helping apply sound practices; high level tools must support more than rapid application generation -- full software engineering support for things that don't look like conventional programs.

So who do you certify? Who is really doing software engineering?

Questions to panel

What will be the impact of certification? Certification of individuals is no use without monitoring activities. Certification should be applied to specific areas, such as safety-critical systems.

What is being actively done to bring the gap between academia and industry? Hands-on experience in (students) capstone projects -- industry has to participate too. Industrial advisory board for program (Parnas); work with engineering organizations (run by practitioners). Masters in SE (Young) with four universities and industry.

Defining a good design in software is difficult -- how would you teach the ability to produce a good design? Domain-specific. Industry needs to build "lists" of knowledge required by a software engineer.

Stratification of software development -- how does one provide experience at the higher levels?

Tom DeMarco

Ok, we're imagining a child with a learning disability... Hope, her name, is your organization. Reason she has a learning problem: learning is to mind as healing is to body. Like healing, learning is going on all the time -- there is no switch to turn learning off. But learning can be wrong: learning short-term, learning something else, learning and unlearning.

  1. What it means to be a learning organization.
  2. History of organizational learning.
  3. Who learns in a learning organization?
  4. The key organizational change to facilitate learning.

What it means to be a learning organization. Example: Amazon.com moves its warehouse to Memphis Tennessee, adjacent to the FedEx runway (Nicholas Negroponte). Observation: alternate ways of managing the supply chain.

Characteristics of learning organizations: get out their boxes, rethink the rules, redefine the rules, BUT still stick to the knitting.

History: 1950's had classic hierarchy. 1970's introduced matrix management -- program managers on one axis, area (expertise) managers on other axis. The "important" axis can be swapped. Problem: cost of "splitting" a person between projects -- fragmentation penalty is ALWAYS greater than 20%.

The essence of our profession is team involvement, and you can't be a member of five different teams.

1980's: Project structure plus QA (parallel tree). These days hierarchies are much flatter than previously. Counter-example with "binary" management tree -- but not really a tree -- the management part of the tree itself forms a management team.

Bad approach: one guy learns something, everybody else underneath gets told. Bad approach: learning doesn't happen from the bottom either. Conclusion: learning happens in the middle. (Too bad American companies have trimmed out the middle.) The real "learning center" is the "white space" in the middle of the organization.

Basic hygiene: 1. keep your people; 2. "drive fear out of the organization"; 3. relax control. People need to be given a chance to make mistakes.

Problem: management does not communicate -- "cheating." The thing that makes a great team is common ownership of a great product. This needs to apply at the management level as well as at lower levels.

Nobody can learn if they feel unsafe. Feeling unsafe is not the same as fearful -- you can still learn. By unsafe, he means fear of ridicule, or of being demeaned. Meaningful learning happens in the presence of peers who are also learning.

Problem with flatter hierarchies: people in the key learning positions are isolated, embattled, frightened, overworked. Or gone. If everybody is busy 100% of the time, there is no learning space.

True learning is very scary, because you realize that you've been missing an opportunity all these years. The hard stuff is what you have to focus on.