What is the intended resultant mindset of this “Open Software Engineering Curriculum”? We will call it ‘Systemically Sustainable Innovation’ instead of disruption. We will develop it by examining two works: “A Whole New Engineer” (WNE) and “Rethinking Engineering Education: The CDIO Approach” (REE), and showing how ‘Crystallized Engagement’ is its formative paradigm.
Take the example of the obsolete bionic eye implant, “Second Sight” made for people without vision. The implant stimulated the retina of the patient with electric pulses based on a low-resolution separate camera feed which created a basic sensation of vision. Eventually the company went bankrupt and as devices failed, there was no possibility of replacement parts or support. Patients were left with non-functioning eye implants that complicated future medical procedures. Due to the low market size and high specialization, a secondary manufacturing process would not be financially viable, even if the designs were released. This illustrates several different aspects of ‘systemic sustainability’: The long-term technical reliability of the device was not proven. As an industrial process, low volume production and support could not achieve economies of scale. The company’s financial viability was tenuous because of a smaller-than-expected market and high costs of sales, regulatory compliance, and rehabilitation after implanting the device.
As a new product, it created a new dependence, which in turn created a new responsibility of care that could not be sustained as a system. While engineers should have freedom to innovate, they must also be mindful of the long-term implications of any new technology, which starts with its specific sustainability. Engineering education ought to foster this mindset through direct practice, which is the intention of the ‘Crystallized Engagement’ approach.
This formulation came, in part, from reflection on two recent works on engineering pedagogy. “A Whole New Engineer” by Goldberg and Somerville presents the story of Olin College and the University of Illinois’ iFoundry engineering program. Through experiential learning (Do-Learn), an emphasis on teamwork, and a focus on the joy of building, these institutions and the “Big Beacon” movement hope to bring about a cultural change in engineering education. We will contrast this with “Rethinking Engineering Education: The CDIO Approach” by Crawley et al. which presents a systematic consideration of each step of the engineering process (in their account): Conceive, Design, Implement, Operate and describes how to integrate them into the core content of engineering program. REE seeks to also weave professional skill development into these courses as a positive sum interaction instead of a time trade-off (p. 33). WNE is a vision statement for a different kind of culture in pedagogy: one that replaces weed-out thinking and competition between students with collaboration and personal development. It isn’t a how-to guide. REE is a bit narrower in its self-conception and isn’t tied to specific institutions in the same way that WNE is. It goes deeper into the methods of program development and evaluation. Both have theories of institutional change, and in particular how to move from courses based on Direct Instruction to a problem-based curriculum with projects integrated from the beginning of coursework. Neither acknowledges the other, despite many similarities and likely opportunities for the social networks of the authors to overlap.
But more importantly, neither gets the full life cycle of engineering right, which does not prepare students for thinking about systemic sustainability. As described in the previous essay, the ‘Do-Learn’ or ‘Structured Exploration’ approach to pedagogy allows technical problems to drive learning of the core engineering content. From there, projects give the opportunity to quickly plan and build prototypes that demonstrate the concepts presented within the courses. The CDIO approach, on the other hand, places a stronger emphasis on methodical Design after the initial “Conceive” phase, and also includes the “Operate” step. To operate a new product for an extended period of time naturally leads to thinking about reliability in a way that rapid prototyping does not. In “Rethinking Engineering Education for the 21 st Century” by Richard Miller, Olin’s first president, ‘sustainability’ is listed as one of the key modern challenges, but is not in the presented nine core competencies within engineering, and long-term operation is nowhere mentioned as an important part of the curriculum. Olin’s “Do-Learn” and project-based courses have what we would call Explore, Learn, Conceive, and Implement as the core steps. New problems or application areas often call software engineers in particular to learn about new domains even within the scope of a project, which means that they need intentional practice of Exploration and Learning at the beginning of any new venture. Altogether, our proposal is a union of these two approaches into the complete “ELCDIO” cycle within Crystallized Engagement. This full project cycle will take more time than the traditional project framing, but we believe it will pay off in the resultant change in mindset.
From here, we will examine the different kinds of sustainability. Engineers must first learn to get systems to work reliably, which we can call “Technical Sustainability”. There are several important obstacles to cultivation of this mindset within the curriculum. Reliability doesn’t carry the same appeal as disruptive innovation, and often doesn’t require the same level of theoretical depth that professors naturally want to impart in their curricula. When professors go to industry for technical consulting, they are usually involved at a low level of Technical Readiness because that is their comparative advantage and where their expertise is actually needed, and rarely in the reliability engineering of existing products. This can give them a skewed understanding of the future practice of engineering for most of their students. Or, they can discount reliability as something that can be learned on the job and not worth core curriculum time.
Further, the desire to cover a large body of theoretical knowledge leads to a mindset and habit of speed over quality. In school, a score of 95% is typically an A – the highest grade. In software, getting something 95% right means that the code doesn’t build, 97% right: it doesn’t pass unit tests, 98%: doesn’t pass integration tests, 99%: doesn’t deploy, 99.9%: you or someone on your team gets paged at 3 AM weeks later for an untested edge case that renders your system non-functional until you roll back the change or deploy a hot fix. In other domains of engineering, there may be design margins (for example, in load ratings of structures) to allow for error, but large margins are materially expensive. In practical engineering, you and your team need to re-do things until you get them right and not merely move on to the next project. Project-based learning often turns into making something technically interesting that barely works for the demo and then discarding it. The high-coverage low-repetition approach of most programs is fundamentally opposed to a mindset of reliability. This is not to discount rapid prototyping as a valuable skill, but it needs to be balanced with taking a product to a steady state at least a few times within the curriculum. Such ventures lead students to a better appreciation of the value of simplicity because of its alignment with reliability.
“Engineering begins and ends with people” was a repeated phrase around Olin and in its guiding documents. It’s true – but in common engineering practice its primary sense is different from what the authors likely intended, which brings us to the second kind of sustainability: organizational. Almost all engineering happens in organizations where the first kind of ‘centering engineering on people’ is being a good team player. While engineering projects should of course be ordered toward the benefit of the end user and society, the day-to-day practice is learning from previous efforts, training new people, evaluating and extending experiments that other people did, and presenting new designs to others. Organizational sustainability, as an objective, comes from the need to preserve this system of interactions between engineers to transmit theoretical and practical knowledge through time. Through most of the history of technical disciplines, apprenticeships within guilds transmitted this knowledge by active application. As the mathematical and scientific formalism of technique increased, engineers needed to learn more before this practical application, and so the schooling prior to work lengthened. Alongside this, the professors in ‘polytechnic’ schools spent most of their lives in academia, not in practice, which predisposed them to think primarily in terms of theory and mathematical design. To repeat: when these professors did have industrial engagements, they were at a low level of technological maturity, so professors did not commonly think of sustainment.
The gap between the mindsets of mathematical formalism and practical application within an organization creates the shock that many software engineers have when entering industry, especially PhDs. In a practical setting, software is (1) a high-level user interface to the processing unit’s instruction set (getting the computer to do what you want in an efficient manner) and (2) a communication mechanism between engineers. To simplify things, “Computer Science” deals with what is possible with computers, while Software Engineering cares about doing things efficiently and as part of an organization. Students might have a ‘hacker’s mindset’ (scrappy builder, not infiltrator) and know about getting things to work with few resources, but almost always require a great deal of training on how to write code that is readable and maintainable by others. An engineering program ought to at least introduce these ideas so that students can understand the multiple meanings of “engineering beginning and ending with people”.
Organizational sustainability includes the transmission of practical knowledge through time, and between generations. We can look at one example of a failure of such transmission. Fogbank was a secret material used in the production of nuclear weapons. Manufacturing processes were discontinued in the mid-1990s, and when engineers tried to restart them in 2000, they could not replicate the original process. Most of the staff involved in the prior production were gone and the equipment available was similar but not the same. Eventually, they recognized that material impurities in the original process were critical to its success and were able to recreate it in 2008. Because it was a secretive and specialized process, they could not rely on well-established or common knowledge. Knowledge transmission is rarely this challenging, but this example illustrates how products are the output of engineering organizations that are effectively living systems.
The remaining kinds of sustainability are farther from the day-to-day practice of engineering but are worth attempting to integrate into the course of education. “Industrial sustainability” relates to management of systemic risks such as low volume production, using specialized inputs with few providers instead of commodity components, geographically distributed supply chains, and having a small number of consumers. Commercial enterprises all want to create distinct products without comparable competitors, but these same enterprises and private consumers want to pay commodity prices in a competitive market for what they buy. Navigating the gradual commodification of products through time is needed to financially sustain any business. Financial sustainability also includes models of return on capital investment, accurately assessing non-recurring engineering versus continuing support costs, and the general management of a business. Finally, environmental sustainability needs no introduction here but should still be included in the curriculum.
So how can an engineering curriculum promote the proposed mindset of systemic sustainability? (1) Ownership of a single product through time while progressively adding features to it to increase technical depth, (2) habit formation through working with users over extended periods to support a product, and (3) explicit assignment of professional competencies to courses. These goals come at the cost of a highly modular structure in which there are only dependencies of theoretical knowledge between courses.
Because “Operate” is the most foreign part of the ELCDIO cycle to typical pedagogy, we need to spell out what it could look like. Imagine a simple “weather station” that monitors wind speed, rain, humidity, sunlight, etc. and is physically deployed. To put together such a weather station requires integration of microcontrollers and basic circuits, as well as simple mechanical design to enclose it and make it resistant to the elements. The physical system must be maintained through time, over months or even years, and can be progressively improved in response to problems. Once it is deployed as a system and reporting data, the data stream can be processed and uploaded to the cloud. Visualizations can be built on the data stream within a simple website. The data set presents opportunities for analysis and predictive modeling. Multiple stations can communicate as a mesh network. Starting from even a simple measurement device, there are many avenues for problem-based technical depth within software engineering across the product life cycle. The practice of physical and software maintenance within this project helps to prevent a mindset in which “everyone wants to invent the future, but no one wants to be on the future’s on-call rotation”. All of the technical features are built upon the continuous proper functioning of this device and data pipeline.
Students can learn how to care about long-term effects and sustainability of products for the people using them simply by working with them over longer periods of time. Olin’s “Engineering for Humanity” is an introductory design course that pairs students with seniors and has them try to solve problems that they face, often centered on negotiating the physical environment. Working with seniors in this way has many advantages: physical objects are often not easy for them to use, and so there are plenty of opportunities for assisting them. Solutions can be inexpensive. Seniors are often overlooked, generally have a lot of free time, and are happy to talk to young people who want to help them, so they are an ideal user group. By extending this engagement beyond a semester-long course and doing long-term support for these projects, students can gain an appreciation for lasting impacts on users as well as technical sustainability (again, from the value of simplicity).
To address the other major domain, organizational sustainability, students should work in teams, write and defend documentation, and conduct detailed design reviews with other students. While many professors recognize teamwork and technical communication as important, they don’t devote enough effort into methodically cultivating them. Some seem to believe that given the opportunity, most students will naturally develop team skills. In practice, it is a skill that can be learned by doing but accelerated by complementary instruction. Similarly, the “easy way out” of including technical communication in the curriculum is to have oral presentations of projects at the end of the semester, assessed in a rubric. But this does not match professional practice, and rubrics typically do not offer much in formative evaluation beyond directing students to develop their skills in some aspect of presentations. To prepare students in organizational sustainability, they must write reviews of and respond to feedback on designs and documentation. If resources allow, professors should evaluate the quality of these written reviews. Or, other students can assist in providing meta-commentary. The challenge of defending one’s designs to one’s peers and reviewing others’ is the core of industrial practice. To achieve Crystallized Engagement, the curriculum should explicitly assign these competencies to specific courses.
Finally, note that not every project needs to have the full ELCDIO cycle, but each step should be included multiple times and in conjunction with other steps. Some projects and courses will focus on systems integration in teams, rather than increasing theoretical depth. Detailed design reviews and long-term support should begin early to plant the seed of the comprehensive CE mindset.
Mike's Engineering Blog 