TomOwens

The headline here is very misleading. The article isn't saying that ethics isn't currently part of engineering education and should be, but rather that the way ethics is embedded in engineering education could be improved.

The actual title of the article is "We Need to Embed Ethics Into Our Engineering Courses > Adding social responsibility to technical training prepares students to protect the public good".

Specifically, the article says that current "curriculum requirements tend to be unhelpfully generic and minimally enforced" and that ethics education comes "through introductory or non-engineering coursework, where the focus is on codes of conduct and academic integrity, rather than deeper topics of social responsibility". They go on to cite some numbers: "only about 4 in 10 engineers in the United States recall receiving" ethics instruction in engineering courses and "3 in 10 report never receiving training on their public welfare responsibilities at any point in their careers".

The authors talk about how they build out tools for undergraduate engineering education for (1) embedding ethics modules in foundational courses and (2) a course dedicated to public welfare responsibilities for engineering.

I agree with the authors that embedding ethics into undergraduate education is important, but I find it surprising that so few engineers report receiving it during their education. I was in an ABET-accredited engineering program, and we had a section on ethics built into a number of courses. But maybe this only supports their point about how inconsistently it's taught or the accreditation guidelines are enforced. I do think a dedicated engineering ethics course would be helpful, though.

Precise terminology is important. Just like there's a difference between "taking a photograph" and "photography", there's a difference between "making software" and "software engineering". Digital cameras let more people take more photographs, and some decided to practice the art of photography. Every technological advancement, from personal computers to widespread Internet access to AI tools has made creating software more accessible, but it hasn't inherently made more software engineers.

"Writing code and building products" isn't engineering.

I think it's true that making software has gotten more accessible. That's been happening for a long time. I remember the whole deal about "low code and no code platforms are going to make software engineers obsolete", and that never happened. Various platforms offered tools for non-developers to work with data and build integrations, but the most complex work still required people with expertise in design and testing.

Someone like Samuel Florman would probably point out the social responsibilities that come with engineering, Henry Petroski would talk about how the people who are using AI tools and "vibe coding" don't have an understanding of edge cases and failure, and Eugene Ferguson would talk about how AI tools create a gap between prompts and design in the mind's eye. People with different takes on what it means to do engineering would find that an engineer can use AI tools in their work, but creating software with an AI tool isn't inherently engineering.

This is right. Not only are ethics courses required for accreditation, but ethics is built into a number of other courses. It was primarily the design courses, but there was usually at least a module on some kind of ethical failure in whatever system the course was covering, like embedded, enterprise, or whatever.

I suspect that testing22321's program is what Steve McConnell called software _engineering_, as opposed to the software engineering program that I went to, which is aligned with McConnell's _software_ engineering.

There's a chapter on this in McConnell's Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers.

His example of software _engineering_ was McMaster University in Canada, where the graduate could achieve licensure by taking and passing the appropriate exams. Courses include materials, thermodynamics, electricity and magnetism. His example of _software_ engineering was based on (an older version) of the program I went to at RIT, which covered courses in software project management, software engineering process, and a lot more software systems design. Both had similar math, computer science, and software development courses, but I suspect McMaster would have courses in linear algebra and multivariable calculus that I didn't have.

Are American developers missing something? We missed out on the opportunity to get licensed in the mid-2000s and 2010s. People who went to _software_ engineering programs probably couldn't pass an FE exam unless they took (and remembered) a bunch of courses that have little to do with building software and would fall outside their normal academic program. I'd say that the software _engineering_ programs that don't get into the nuances of how to manage organizations and teams building software systems are the ones missing useful knowledge.

Yes - fixed that. Thanks.

For the past couple of months, I've been doing a deep dive into engineering and engineering philosophy, and I have some thoughts about this article.

The biggest thing I noticed was that, even though there was an acknowledgment of the lack of a singular definition of engineering, the definition used throughout was tied to a linear model of innovation. I've been able to trace this thinking to the 1920s, with a growth in popularity in the 1940s and 1950s. A prime example is Vannevar Bush's Science: The Endless Frontier. Although the report had some good outcomes, like leading to the establishment of the National Science Foundation, Bush's own autobiography acknowledged that this model was a disservice to engineers and engineering, as it led to many engineering accomplishments being touted as scientific achievements and scientists getting credit for the work of engineers in popular literature and the press.

There aren't too many other views of engineering out there. A handful of contemporary authors keep coming up: Florman, Vincenti, Ferguson, Koen, and Petroski. Most other things I've read tend to cite one or more of these authors and continue to build upon their foundations.

Picking up any one of the other perspectives on engineering would let you make another connection to the 1968 NATO conference. There were really three camps that offered definitions about what software engineering should be. People like Dijkstra, Hoare, Naur, and Wirth focused on applying mathematics and computer science and on theory building. McIlroy, Bauer, and Bemer looked at how software development could learn from industrial engineering and mass production. David and Ross emphasized practical problem solving. By the 1969 conference, the practical problem-solving piece had dropped out of focus, even though this is very closely related to how other engineering philosophers looked at engineering.

Another aspect from some of the engineering philosophers is the craft roots of engineering. This also tends to disprove the linear model of innovation. Engineering existed well before modern science, and there are several cases of engineering development without a robust scientific understanding of the principles that enable it. Modern science became a tool in the toolbox of modern engineers, but it's not a precursor to engineering. The craft roots have been there all along and were part of engineering education up into the early 1900s. This can tie back into Agile Software Development and the software craftsmanship movement of the 1990s and early 2000s.

The paragraph about application programming being removed from the debates in the 1960s misses a key point. In the 1960s, "software" was shorthand for "systems software", or the stuff provided by computer manufacturers to allow people to make their computers do stuff. Application programs were not really considered software until at least the 1970s. It's a bit nuanced, but there's a reason for excluding this group of people: it was seen as a different thing entirely.

Finally, no mention of Margaret Hamilton. Failing to even mention Hamilton and her use of software engineering as an aspiration to elevate programmers to the same status as the other engineering disciplines on the Apollo program misses a huge moment in the development of the idea of software engineering.

That depends.

People who are around developers, often yes.

Whenever someone doesn't get it, it's easy enough to explain in one sentence: Technical debt is the result of decisions that we've made, willingly or unwillingly, or knowingly or unknowingly, that make changes slower and riskier.

I don't think that "mess" is a good synonym for tech debt.

Martin Fowler wrote about the technical debt quadrants, and "mess" seems to cover 1/2 to 3/4 of the quadrants. I don't think it accurately describes the case where you need to deliver quickly and knowingly accept the consequences of less-than-optimal decisions.

There's also no reason for teams not to track their technical debt. Although some kinds, like what Fowler refers to as the inadvertent side of the spectrum, may not be known right away, you can at least track the need to correct deliberate poor choices. Traceability to architecturally significant system elements or user-facing features can help account for where the debt lives and how it may impact future effort.

The metaphor of debt isn't perfect, but calling it "mess" is even further from reality.

And what happens when the agent modifies or skips tests or finds other ways to circumvent the constraints? There are already examples of agents trying anything they can to achieve the objective. The code is the one source of truth for the system's behavior, so beyond rapid prototypes that will be thrown away, I don't see how a human can set aside accountability for changes made by an agent.

Dave Farley's book is really good, and I'd highly recommend it.

However, I do have an issue with his focus on applying science in the definition, even though it doesn't come across in his final conclusions. In the history of engineering, that's a relatively new development. It started, to some extent, in Europe in the 1700s, but it really took off in the 1920s and exploded in the United States after World War II (1940s-1950s). It culminated with the Report of the Committee on Evaluation of Engineering Education (the Grinter Report) in the mid-1950s.

This isn't to say that science isn't important to engineering, since it absolutely is. Science provides knowledge used to better understand the world being changed by engineering. But there are also plenty of examples of engineering going ahead of science - the steam engine, the airplane, generative AI. We didn't fully understand the governing rules before the technology existed.

Any definition of engineering needs to be broader. Ferguson (Engineering and the Mind's Eye), Florman (several works, but primarily The Existential Pleasures of Engineering), and Vincenti (What Engineers Know and How They Know It) all explore ways in which engineering can't rely on science alone. I think Koen (Discussion of the Method) puts it best, where the application of science is one heuristic that engineers may choose to draw upon.

Having a bottleneck with AI-generated code is probably a good thing.

Consider before AI. In cases where code was written by a trusted human, you had confidence that they were doing the right stuff - the people understood the context and requirements, the changes were based on those requirements, and tests were updated. You could rely on some basic automated checks to run a linter and static analyzer, execute the tests, and check test coverage. You can defer longer-running tests to a later stage, but people can merge their work in and collaborate. You can have blocking reviews for untrusted outside contributors or new employees and review the rest later.

After AI, the input is a mess. I haven't personally seen the worst of it, but I've read about people generating code before any requirements development or analysis. Code is generated without understanding what it is supposed to do, which also prevents good testing. Even with good requirements, people generate solutions that aren't right, and the generation step may remove failing tests or make unintended changes that aren't covered by tests. So much code is generated from untrusted sources and rubber-stamped. Introducing a bottleneck where a human can slow the process down is a good thing here.

Maybe if we can get people to understand how to use AI tools responsibly and have humans take full accountability for the output and changes, we can get back to the old way. Trusted humans and an AI agent assistant can make changes that are solid enough to merge. Independent control over the pipeline and basic automated checks would give just enough confidence in the change, and delayed review before deploying or enabling the feature would work. But not until trusted humans actually maintain oversight over their tools.

In practice, the frameworks don't work out of the box. Take Scrum, for example. The framework described today has had all the original technical practices used by the first Scrum Teams stripped out, with no new technical practices added, and it's been generalized to fit many organizations so it's marketable. There are many questions to ask. Why do I need to have a Daily Scrum every day? If I'm mobbing, do I need a Daily Scrum at all? Why a maximum timebox of a month for a Sprint instead of 5 or 6 weeks? What technical practices do I need to deliver software every day or week? All of these are important questions that would likely result in changes.

The culture is the big thing.

I've only worked in very large enterprises, but I've never had to deal with a dickhead CEO because they push decisions down. I haven't even had to deal with a dickhead business unit VP or director. Decisions are actively made 3 or 4 levels below the CEO. That's almost always at the product level, which could be one level up from a team if multiple teams work on a single product. I've also rarely had to deal with people being shoehorned in because we strive to eliminate single points of failure. That means having at least two people with (or working toward) a given skill set, cross-training, and being willing to work outside their comfort zone. People who stay in their niche and don't work with others often don't last long, by their choice.

So, yes. These things can work. I've done it. But it means you can't follow someone else's script or a canned framework and set of tools. It means having a deep understanding of why a framework has made certain choices around roles and events and what to change to build something that works for you. But it's also cultural change in the organization because agile ways of working are inherently different than predictive methods - they need different relationships and inputs and create different outputs.

I graduated from a software engineering program accredited by ABET as engineering, rather than as a computing program, which would include CS, data science, information systems, and IT. Even with that, I didn't have much, if any, coursework covering the topics needed to pass the FE exam.

The other issue is when your state has requirements for work experience under a PE. At the time, I was working in aerospace/defense, and we had almost no PEs in any discipline. I knew of two or three PEs, one of whom was a project manager and no longer doing technical work. None of them were in the software organization. Even if people could take and pass the FE exam, it would be hard to get the experience. This one is on the states, though, since they create the requirements for becoming a PE.

What makes it worse is that my undergrad degree almost exactly mapped to the SE PE exam, which was very heavily based on SWEBOK. Before I graduated and before the PE exam was a thing, I started down the path of the IEEE CS certifications, which covered much of the same topics. I stopped that when they revamped their certification pathways.