teaching software engineering is still done wrong

content/post/2022/05/teaching-software-engineering-is-still-done-wrong.md

@@ -0,0 +1,56 @@
+---
+title: "Teaching Software Engineering Is Still Done Wrong"
+date: 2022-05-18T11:25:00+02:00
+categories:
+  - education
+---
+
+When it comes to teaching software engineering, I've been thinking _"We're doing it wrong"_ for a while now, and the recent ACM Tech talk "[Lessons From the Fifty-Year Quest to Turn Programmers into Software Engineers](https://acm-org.zoom.us/webinar/register/WN_uQQ-qGp1RHG4aXK379WLUA)" only confirmed my suspicion. Adam Barr, a seasoned software consultant that was involved in major Microsoft products for years, gave a surprisingly sobering talk by serving us quotes from fifty years ago. How about this one from E. Dijkstra in 1972 (emphasis by Barr):
+
+> It would be very nice if I could illustrate the various techniques with **small demonstration programs** and could conclude with "... and when faced with a program **a thousand times as large**, you compose it in the same way". This common educational device, however, would be **self-defeating** as one of my **central themes** will be that any two things that differ in some respect by a factor of already a hundred or more, **are utterly incomparable**. 
+
+Guess how we still teach software engineering---and computing in general? Right, small demonstration programs! Here's a function:
+
+```C
+int add(int one, int two) {
+	return one + two
+}
+```
+
+Write a unit test for it! Here's one as an example:
+
+```C
+TEST(AddTest, ShouldAddOneAndTo) {
+    EXPECT_EQ(add(1, 2), 5);
+}
+```
+
+There, you now know how to unit-test stuff. What's next? Right, design patterns. Here's a factory---etc, etc. Of course, you have to start _somewhere_, and syntax and ecosystems are usually the first trip wires students struggle to overcome, so throwing them in the deep end by presenting a huge project with thousands of unit tests or all too pragmatically implemented design patterns will be of little help here. 
+
+So we start out small. The problem is, we usually also end small and never neatly string everything together _across courses_. No way, that would mean collaborating with another teacher, woah there. Academia can be a sad state of affairs sometimes, and although this is not always the case, it's much more common than you think. It's somehow surprisingly hard to present a uniform picture to the students from the teaching staff as _one team_ instead of a collection of individuals with their own style and preference for tooling, that causes further confusion. 
+
+Within my own courses, I try to relate the small examples to the work field by digging into source code from bigger repositories available at GitHub. It's both educational and a lot of fun to dabble in the Quake 3 or BoardGameGeek app source code, looking for examples of dependency injection and smart usage of factory classes (or, in the case of Quake's C code, structs). What is strange, however, is that this problem is far from new, if we are to believe Adam Barr. Here's another lovely quote, from Harlan Mills in 1980:
+
+> If precision and scope are not gained in university education, it is very difficult to acquire them later, no matter how well motivated or adept a person might be at individual, intuitive approaches to problem solving.
+
+Barr explains that academia overly focuses on what he calls "individual problem solving": small subsets of algorithmic problems, that have little to nothing to do with real-life software _engineering_ problems. Another classic example would be teaching and proving complexities of various sorting algorithms. Sure, they have their use, but mastering those problems by hacking away individually has little to do with team-based software _engineering_.
+
+I used to think that the difference between the titles "programmer" and "software engineer" is just a matter of vanity, but in Barr's context, a programmer will struggle to pick up the role of a software engineer, and in university, we're teaching students to become programmers, while we actually need software engineers. Stop focusing on performance and algorithms. Focus on readability and code. The same is true for research, according to Barr: where is all the empiric software engineering research that focuses on how writing code in practice works? Instead, we're publishing heaps and heaps of... individual program analysis results?
+
+Isn't it telling that in the seventies, both academics and industry experts like Dijkstra and Mills warned us that this ain't the way to teach computing? Fifty years later, the situation hasn't changed much. This isn't just according to Barr, or according to my personal experience with teaching, but also according to the research I've encountered en conducted myself by [analyzing learning outcomes](https://people.cs.kuleuven.be/~wouter.groeneveld/courses/) of computing-related course material across European universities.
+
+There is no single explanation for this, but I feel that we aren't really trying to solve it. Instead, we're just minding our own business and securing our position by upping the P score through publishing _stuff_ (anything goes!). I've been known [to criticize how academia works before](/post/2021/05/a-critique-on-manuscript-review-procedures/), and although I have little influence, I have the feeling the critical mass is way too small to radically innovate in that world.
+
+Adam Barr warns academics that code bootcamps might take over---and perhaps rightly so. A few other observations that might contribute to the issue:
+
+- In academia, programs and code is throwaway garbage---_write-once_ objects to grab results and publish. This emphasizes the wrong aspects (Barr's algorithms VS clean code).
+- There are too little entry points to conduct empirical software engineering research using "real people" instead of students as the test subjects.
+- The structure in academia is much too rigid. Its culture facilitates slow reactions, individualism, and focus on research instead of education, with little incentive to change.
+- There is surprisingly little real-world experience within academia. Most professors never really faced Dijkstra's "a program a thousand times as large", so how are they supposed to teach how to handle that?
+
+Barr ended his talk with a few recommendations: let students taste real-world code by exploring open source projects, give them bigger open assignments, etc. These conclusions can be read in pretty much every single paper on computing education, and as good as this practical advice is, I wonder why it's almost never taken to heart. Even if it is, will it be enough?
+
+All things considered, in my opinion, the future is looking bleak. I'm still convinced students really start learning as soon as they graduate and start working. Hopefully they end up in a company that cares about life-long learning, assigns them an amicable coach, and employs pair programming to quickly bring their knowledge above the minimum level. The more I think about this, the less I think academia---at least in its current state---will be able to rectify this. 
+
+And without a critical mass, there's little I can do besides getting even more frustrated.
+