A perspective on the ICS Software Engineering Curriculum
--
Cam Moore sent me excerpts from essays his ICS 414 (Software Engineering II) students wrote this semester (Fall 2021) about their class experience. Here are a few:
- Even though ICS 414 did not have any lectures, no exams, and no
assignments, I feel like this probably has been my most valuable class
yet. With my interest being in software engineering, being able to
take a class that provides a realistic approach as to how software
engineering is actually done in the tech world has been very
beneficial to me and my computer science career. From running into
communication issues with the client, to having issues within the
development group, to improving my problem-solving skills and self
learning skills, I feel like I have gained valuable experience on how
a career in software engineering may be like. Because of this, I feel
a lot more confident in my ability to become a software engineer, and
I feel like I have a significant advantage over my peers trying to get
into the same career choice. With all the problems and lessons learned
while taking this course, I really feel like ICS 414 provided me a
glimpse into my future, and I have never been more excited for it. - During the entire semester of ICS 414, there was no lectures, tests,
quizzes or any of the standard things one would do in a class and that
would make you think that you learned nothing at all! But not ICS 414,
even though there was none of that I felt I’ve learned more from this
class than any other class in the whole program of Computer
Science. Going from having to work with a actual client with a program
and this features and have it built by a certain deadline or to
working with a bigger group than normal is all something that can push
me towards a career after I graduate. - Conversations with an old friend is what meeting ICS 414 for the first
time was like. It presented itself with familiar content that for the
most part were covered in ICS 314. It is overall a fun roller-coaster
of a course. Its structure was project-based and significant amount of
the course material stems from cultivating ones skills in the work put
in these large set of groups. Course material includes knowledge of
MongoDB, Javascript, Intellij IDEA, Github, Semantic UI, Meteor, and
React. - My experience in ICS414 was an unforgettable one. I enjoyed every bit
of this class and I know that everything I learned in this class will
be useful to me in the future. I’m grateful for this opportunity to
have a customer and experience what it is like to work with a customer
and create something that is providing for someone’s needs. Thank you
to my teammates who put in a lot of time and effort into our project
to create something I never thought I could do. I can’t wait to see
what the future has in store for me!
I am highlighting these results because I have been deeply involved with the ICS software engineering curriculum for 30 years, and these are the best reviews of ICS 414 I can ever remember seeing. My motivation for writing this essay is to provide a perspective on why ICS 414 worked so well this semester, in hopes that this positive experience can be maintained as the software engineering curriculum changes in both content and instructors in the future.
tl;dr
For those who don’t want to read the entire essay, here are my three “prime directives” for how to create a high quality software engineering experience for our undergraduates:
1.Software Engineering I (ICS 314) students should learn a “comprehensive” tech stack.
2. Software Engineering II (ICS 414) students should use that same tech stack to solve a problem for a real world customer.
3. The instructors of Software Engineering I and II must be fluent with the tech stack.
Interestingly, the past three semesters have been the first time in 30 years that all three of these conditions have been met.
About Software Engineering I
I have had primary responsibility for Software Engineering I (ICS 314) for many years. After a great deal of experimentation, I developed a pedagogy called “Athletic Software Engineering” and a curriculum that blends the introduction of standard software engineering concepts (configuration management, quality assurance, UI and application design, testing, etc) with a tech stack for web application development. The module page for the course website (https://courses.ics.hawaii.edu/ics314f21/) illustrates the course content:
ICS 314 assumes only introductory knowledge of programming. With respect to the tech stack, it introduces a language (Javascript), a development environment (IntelliJ IDEA and ESLint), a configuration management system (git and GitHub), a NoSQL database system (MongoDB), an application framework (Meteor), a UI Framework (React), an agile project management paradigm (Issue Driven Project Management), a deployment system (Digital Ocean), a continuous integration mechanism (GitHub Actions), and acceptance testing (TestCafe).
Students consistently give the current incarnation of ICS 314 extremely high ratings. Here are a couple of representative comments:
- Professor Johnson’s course is the course that breaks open the field for students, in my opinion. He provides us the tools to effectively collaborate as a team when working with code and how to make the modern designs that we see today in sites. This course is definitely something I dreaded while taking, since the work load can be a little much at times, but if you properly try to understand how everything works, the knowledge gained can stay with you for life. It’s honestly insane. (Fall, 2019)
- The work load is a lot but it’s really fun to see the possibilities that can be done because of it. I enjoyed the course and never felt burdened to do any of the coding assignments because it was so engaging. As long as you keep doing the assignments you are supposed to, you can stay on track and learn efficiently. Its broken down concepts that you gradually learn and by the end, you come out with a great amount of knowledge than before. This is probably one of the best courses you’ll take as it will apply far beyond school. (Spring, 2020)
I developed Athletic Software Engineering as a way of helping students to successfully learn the material in ICS 314. It is one thing to simply throw a large amount of material at students, and it is quite another thing to develop a pedagogy and classroom environment that enables most of them to successfully learn this material.
Although I think Athletic Software Engineering is a pretty cool way to teach this material, I do not think it is essential to the continued success of the software engineering curriculum. Other instructors might come up with very different, yet equally successful ways to engage students with the content.
What I think is essential is that ICS 314 teaches students core software engineering principles in the context of a “comprehensive” tech stack. By comprehensive, I mean it should be sufficient for them to work in groups to design and deliver working applications with a modern user interface with some level of quality assurance.
I know from lots of feedback that teaching such a tech stack is a total game changer for students.
What I also know is that I do not know how to teach this tech stack in one semester and also have them solve a real world problem for a real world customer. It’s too much. In ICS 314, they spend approximately 11 weeks learning the tech stack, which leaves only four weeks to practice the use of the entire tech stack. This is only enough time to develop a more-or-less “toy” application. The result of ICS 314 is that most students are fairly comfortable with a useful tool kit for software development, but no significant experience applying it to a real world problem.
Less optimal ways to organize ICS 314 and 414
Over the years, we’ve tried organizing the software engineering curriculum in several other ways, but none of those were as successful as the current design.
When I first started teaching the software engineering curriculum in the 1990’s, I taught the course from a large software engineering textbook. I received poor reviews for the course: students said it taught only theoretical concepts and didn’t give them any sense for what real world development was like.
Next, we redesigned the two semester sequence to mimic the waterfall development model: the first semester involved requirements and design, and the second semester involved implementation and testing. As much as possible, we involved “real world” community members. The problem with this approach is that first, the waterfall model is a poor model for software development, and second, it is hard for students who do not understand implementation to do an effective job of requirements elicitation and UI or system design. They ended up more-or-less wasting the entire first semester, then felt overloaded by the amount of work that needed to be done in the second semester.
Next, we essentially de-coupled the first and second semester experiences due to staffing issues. This meant that students in ICS 414 did not build upon the tech stack skills they developed in ICS 314. In some semesters, the final project results for ICS 414 seemed significantly less sophisticated and useful than what they developed for ICS 314.
It is only in the most recent few semesters that ICS 314 and ICS 414 have been re-integrated as a coordinated two semester sequence in which students in ICS 414 actually practice the use of the tech stack they learn in ICS 314, but in the context of a real world problem with a real world customer.
At some points during its history, ICS 414 has been taught in such a way that students were told to “pick their own tech stack”. Those semesters resulted in poor quality final projects. I believe that one reason the current ICS 314/414 sequence is working so well is because both instructors are skilled with the tech stack, and because students are required to use the tech stack that the instructors are skilled with.
Possible ways to evolve the software engineering curriculum
Here are some ideas on how the current software engineering could evolve in a manner consistent with the three prime directives listed above:
- Change the pedagogy. As I said previously, I don’t think Athletic Software Engineering is essential to a successful experience. There are other modern pedagogies that have demonstrated good outcomes. For example, studio-based learning appears to be a promising approach.
- Change tech stack tools. Any software development tech stack must evolve to keep up with best practices, and the ICS 314/414 tech stack is no exception. For example, in the past few years we’ve swapped out Blaze for React, Mocha for TestCafe, Bootstrap for Semantic UI, Eclipse for IntelliJ IDEA, and Galaxy for Digital Ocean. Cam and I have discussed moving back to Bootstrap from Semantic UI, and to Visual Studio Code from IntelliJ IDEA.
- Change the language. While Javascript currently works really well, it is only a matter of time until another language will be more appropriate. Cam and I have discussed moving to Typescript, since that’s what we use for our research projects, but haven’t committed to the switch yet. A more dramatic move would be to Python, because that would also necessitate moving to a Python-based web application framework such as Django.
- Change the application domain. While web application development is a really excellent choice for ICS 314 students for a number of reasons, it’s not the only possibility. One possible alternative application domain is mobile application development. I’ve recently been playing around with Flutter, which is based on the Dart programming language, and both of these technologies have a lot to recommend them.
When considering changes, it is important to ensure that the faculty teaching software engineering are committed to becoming fluent in the new technologies so that they can provide appropriate support to the students. In addition, if the changes are radical (such as a change in application domain), then there will be a bit of a transition period in ICS 414 in which the current and past tech stack must be simultaneously supported (this is because students in ICS 314 can choose to take a semester or two off before moving on to ICS 414. It’s not common, but it does happen.)
Outcome measures
How do we continue to ensure that ICS 314 and 414 continue to provide a high quality experience as it changes in content and instructors? I think it can be done by gathering both internal and external outcome measures.
Internal outcome measures
The UH Course Evaluation System provides a very simple way to obtain internal outcome measures. There are standard questions asked every semester. Here are some example outcome measures from the UH CES for both ICS 314 and 414. The values are averages for the courses from the past few semesters. I also include recent values for UHM and ICS for comparative purposes:
As you can see, ICS 314 averages at least 4.6 out of 5 for all the selected outcome measures, which is significantly higher than the UHM or ICS averages. ICS 414 outcome measures are not yet at the level of ICS 314, but still average above the ICS outcomes.
External outcome measures
There are opportunities to assess the software engineering preparation of our students from outside the university system. Interviews with community members, particularly those who have a long-standing relationship with recent ICS graduates, can provide insight into whether things are improving or not.
In addition, one can look to community events such as the Hawaii Annual Code Challenge for insights. Between 50–100 ICS students participate in any given year, and their results for 2021, 2020, 2019, 2018, and 2017 have been impressive.
Enhancing software engineering education in ICS beyond 314, 414, and 613
There are currently three courses in the ICS curriculum that focus on software engineering. If the department decides to increase its emphasis on software engineering, how might that happen?
I do not think that the most efficient and effective way to accomplish this involves the addition of new courses. Instead, I think that the way to increase the emphasis is to make software engineering more of a “cross cutting concern”, such that software engineering tools and techniques become a regular feature of all upper division courses.
To provide guidance on how this could occur, I wrote an essay for ICS Faculty called Ten ways to integrate software engineering throughout the curriculum which provided suggestions on both what to do, and how to do it.
I have not yet seen much adoption of these ten suggestions, but perhaps that will change in the future.
