A Reflection on Waterfall Design

For the senior project class I am currently taking we are using the waterfall design pattern. Waterfall is a linear process where each step is only taken once the previous step is fully completed. This means that the research is done first, the design is only started once the research is fully complete, and so on. This model is the simplest of software design patterns as well as the closest to a ‘traditional’ model.

In my previous projects the only true design pattern I had used was agile, when I took Software Engineering 1. Agile is focused on continuous design and development of software. This design pattern is comprised of self-contained cycles of development called ‘sprints’. In a sprint the planning, design, development, and testing is done for a small subset of the final program’s features. All of the other projects or assignments I have worked on did not require any specific design pattern or, in most cases, collaboration with teammates. Because of this I usually chose to not use any design pattern while developing programs.

Waterfall offers several benefits over the systems I have previously used. The design model requires good planning and research ahead of the beginning of development whereas with agile one could make a fair amount of progress into a project without noticing a design problem. This pattern also is more straightforward than others as it follows an intuitive progression of planning, development, and deployment.

The problems with waterfall design are unfortunately just as numerous as its advantages. With waterfall the design cannot accommodate any change in the requirements of the project or any new information about the technologies of project components. Importantly, other design patterns such as agile are better suited to modern software companies who create programs and applications for the general public. These companies are constantly adding features or modifying existing ones, a process which is not covered under the waterfall method.

This leads me to the conclusion that waterfall is better for small systems where the time cost of planning sprints and assigning roles outweighs that of planning the entire project up front, and critical systems which need to be planned clearly and produce well-structured software.

My Background

Today I wanted to dive into my history with programming. I started being interested in programming when I was 12 years old. Like you would expect of a kid that age I was only interested in programming in order to make video games, which lead me to select C++ as the language I wanted to learn. My dad helped me start learning the language by working through an introductory book with me for a little while. However, it didn’t take long for me to lose interest in this due to the difficulty in learning the language but more importantly my own impatience.

Following my loss of interest in traditional programming I picked up Scratch, a block based programming language which was far more kid friendly. I spent a fair amount of time over the next couple of years creating my own small games. There was also a website where users could share their programs with each other. I remember spending time looking through this site until a game design or style caught my eye and then running off to create my own game based on it. While I never created anything large or groundbreaking, these games helped me learn a number of programming concepts.

When I was older, my dad convinced me to try a traditional programming language again. Him and I followed a series of recorded college lectures which taught python to beginners. Following this class I continued making programs for fun as I had done with Scratch using this new medium. I still made some games using python but also branched out and made different types of programs. During this time I realized I was not very interested in creating games but I was interested in programming.

Jumping ahead to college, I started my higher education going to Linn Benton Community College. As I had been home-schooled my entire life, this was the first time I had been in a classroom setting. I was happy to learn that the introductory course was also taught in python. I also learned a new language in the CS 161 and 162 courses because they used Java. One of the last courses I took at LBCC was a course in the C programming language, which was a style of language I had not touched since I was 12.

Since I transferred to OSU, I have learned many new languages. In web development I learned JS, operating systems taught me BASH, and I learned SQL from introduction to databases. The list of languages I have learned at OSU also includes Haskell, MatLab, and C++ among others

I hope to graduate this spring and continue my adventure of programming with a career where I can learn new skills and grow as a programmer.


Welcome to my blog, my name is Owen Haggerty and I am a fourth-year computer science student at Oregon State University. I have been interested in programming since I was very young and started going to Linn Benton Community Collage before I transferred to OSU. The current public health situation has messed with my plans as much as they have with most peoples’ but I have started to find my rhythm recently.

My interests outside of school include studying space exploration and practicing Taekwondo. I have been learning martial arts for close to ten years and am currently the treasurer for the OSU Taekwondo club.