Programming is not software engineering

At Allegheny College, a class of students and I are embarking on a developer development adventure as we take a hands-on approach to learning software engineering. You can participate in our adventure by reading the collaboratively published content on the Developer Development web site and joining our Developer Development Discord Server. As part of the software engineering class the students and I are reading and then publishing an executive summary about selected articles from the following online books:

• Software Engineering at Google (abbreviated as SE): a compelling introduction to the processes and tools used by engineers at Google.
• Fuzzing Book (abbreviated as FB): a savvy, code-focused introduction to the automated tools and techniques for generating software tests.
• Debugging Book (abbreviated as DB): an interactive introduction to automated methods for debugging and fixing programs.

The idea is that the SE book will help the students and I to learn the professional knowledge and skills that we need to develop as developers while the FB and DB books will equip us with the technical knowledge and skills necessary for us to both understand how software engineering tools are built and to build and apply our own software engineering tools.

In accordance with advice from well-known software engineers like Addy Osmani, who recently published a blog post entitled “Write about what you learn. It pushes you to understand topics better.”, the students and I will be writing a short précis about each of the articles in the Developer Development schedule. Today’s article, and the subject of the remainder of this post, is the preface of SE! This précis is written from the perspective of an instructor who wants to effectively teach undergraduates how to engineer software.

The preface of SE makes it clear that programming is not the same as software engineering — even though software engineering certainly involves programming! The authors of SE make the compelling point that software is different than programming due to the following organizational concerns:

• Time and Change: while focused on solving problems with software, engineers must maintain software systems over long periods of time.

• Scale and Growth: all of the people within an organization who build and use software must adapt in both a daily and long-term fashion.

• Trade-offs and Costs: bearing in mind that software and people are always changing, and organization must make decisions informed by trade-offs.

The SE book’s preface explains that it will introduce how the culture, processes, and tools at Google help the organization to effectively create and deploy global-scale software. I’m hoping that the students and I can learn lessons from the engineers and managers at Google so that we can develop as developers! With that said, I see that, as an instructor, I face challenges on the time, change, and scale fronts. How can I ensure that students develop as software developers during a constrained sixteen-week course?

I plan to introduce a number of my strategies through blog posts that I will write until the course concludes at the end of December 2023. With that said, here is an insight into one aspect of my current plans, which are documented further on the Developer Development web site. You will notice that I’ve integrated team-work into every conceivable aspect of the course, ensuring that students learn how to engineer software in an organization. Together, the students and I will run class sessions, write and publish articles, give presentations, assign software engineering tasks, and implement, deploy, and maintain software. We will work in pairs, small teams, and large-ish teams!

So, is it possible to effectively teach software engineering, as defined in the SE book? I’m not yet sure — let’s see! Please follow my blog posts for more details!

Return to Blog Post Listing