Week 79 (8/5/2026 - 8/11/2026)
Hi everyone, welcome to my 79th blog! This is the Week 7 post for CST 438 Software Engineering.
- Describe some of the differences between using an Agile process and using a Plan and Document (or Waterfall) process.
- Agile
- Pros
- Iterative process consisting of short sprints, about a week or two long for each one. This allows Agile to be more flexible and accommodating to changes, since requirements can be easily modified.
- Excluding a few caveats described in the cons section, Agile allows for exceptional development velocity.
- Cons
- If there is a lot of requirement churning, Agile has the tendency of becoming a chaotic process. This is further amplified by the fact that in a pure Agile process, requirements are not typically provided up front. Furthermore, Agile does not naturally give a timeline or cost estimate for a project, adding to its "chaos potential."
- Plan and Document (Waterfall)
- Pros
- Unlike Agile, the Waterfall approach has a much more rigid foundation up front. For example, a detailed plan for the entire project, along with requirements and system design documentation are standard procedure here.
- Due to how much upfront decision making is done, it tends to be easier to come up with a realistic timeline and/or cost estimate for a Waterfall project than an Agile one.
- Cons
- Waterfall uses a sequential phasing scheme as opposed to iterations (also known as sprints in the industry), consisting of the following: Requirements, Design, Coding, and Testing. In some cases, this can really slow a project down.
- Summary
- When it comes to adopting software engineering methodology and processes, this honestly mirrors the field itself perfectly. From my experience, much of what software engineering ends up being about are trade-offs.
- In practice, companies like Amazon and Netflix in the software engineering space have adopted a hybrid of these two processes in an attempt to gain an efficient balance from each methodology. To achieve this from an architectural standpoint, a common solution is an SOA (service oriented architecture). The idea is to divide large projects or functions into microservices that can be developed and maintained by small agile teams of roughly one to six engineers. Yes, there are Agile teams at my company consisting of one software engineer! This is especially due to the advancements in agentic programming capabilities over the past year or so.
That is all for this week, see you in my Week 80 post!
Comments
Post a Comment