Journey through Level 3 Software Development
What I Learned in the early phases About Software Development: Waterfall, Agile, Scrum and the Software Development Life Cycle
_______________________________________________________________
As part of my Level 3 Software Development course, I have been learning that building software is about much more than writing code.
Before a developer starts creating an application, there are decisions to be made about how the project will be managed, what needs to be built, how requirements will be understood, and how the finished software will be tested and maintained.
This phase of learning, I explored some of the different approaches used to manage software projects, including Waterfall, Agile and Scrum. I also learned more about the Software Development Life Cycle (SDLC).
For someone outside the technology industry, these terms can be awkward as there is no basis to really grasp in a programming field, you can still look at some of these terms and gain an idea of the general aspects through a basic understanding of the language associated with the terms used. The easiest way I have found to understand them is to think of software development as a thought experiment as it allowed me to step out of the immediate instance and take it apart slowly and in my own way.
Waterfall: A Structured Approach
The first methodology I looked at was Waterfall.
Waterfall follows a more traditional, structured approach. The project moves through defined stages, with one stage generally completed before moving on to the next.
This can make Waterfall relatively predictable because the team aims to establish requirements and plans early in the project. I can see why this approach could be useful for projects where requirements are well understood and changes are difficult or expensive to make.
For example, highly regulated or structured environments such as government systems or certain banking projects may benefit from careful planning, documentation and clearly defined processes.
However, there is also a potential weakness as changes need to be documented and cannot be looked at in the moment at least not really, as you will not go through testing until the end and then you would have a proper chance to notice and go back to makes changes or fixes.
Something that was brought up during the learning stage was that these changes can be treated as separate projects, such as a new feature may not need to be part of the original SDLC but it’s own separate SDLC.
What happens when the customer changes their mind halfway through the project? Making significant changes can be difficult when the project has already moved through several stages.
This helped me understand an important idea in software development: the best development approach depends on the type of project.
Agile: Adapting to Change
Agile takes a different approach.
Rather than assuming that everything can be perfectly planned from the beginning, Agile recognises that requirements can change as a project develops.
This seems particularly useful when creating custom software, where customers may discover new needs after seeing an early version of the product.
Instead of waiting until the very end to see the finished application, teams can work in smaller cycles, gather feedback and make improvements along the way.
For me, the biggest lesson from Agile is that change isn’t necessarily a problem — it can be part of the development process.
That is particularly important because software users do not always know exactly what they want until they can see and interact with something.
Scrum: An Agile Framework
I also learned about Scrum.
One thing that initially confused me was the relationship between Agile and Scrum, as it seemed like a copy of agile or just trying to frame agile in a more understandable term. This was shown to be not the case.
The way I now understand it is that Agile is a broader approach to software development, while Scrum is a specific framework that can be used to put Agile principles into practice.
Scrum provides teams with a structured way of organising their work, often around short development cycles called sprints, this would also be centred around a more revision based mindset around more of the stages in a scrum cycle.
Like any approach, Scrum has advantages and disadvantages. It can provide structure, encourage regular communication and make progress easier to track. However, it also requires teams to work effectively together and follow the process properly.
So, rather than thinking of Agile and Scrum as completely separate alternatives, I now see Scrum as a somewhat connective tissue that should be linked into each other in some ways to provide a safety net of sorts for each of there faults.
The Software Development Life Cycle
The other major topic I learned about this week was the Software Development Life Cycle, commonly known as the SDLC. This describes the different stages software can go through during its development. A general depiction might look something like this:
Get Adam H’s stories in your inbox
Join Medium for free to get updates from this writer.
Planning → Requirements → Design → Development → Testing → Deployment → Maintenance
The interesting part for me was realising that software development isn’t simple and it is a lot more preparation that can minimise possible issues or problems in further stages of the SDLC.
1. Planning
The project begins by understanding what needs to be achieved and why. Also any possible issues that can be planned for and worked around or avoided while planning and not halfway through development where it may later cause issues.
2. Requirements
The team identifies what the software needs to do and what users or customers expect from it.
3. Design
The developers and other team members work out how the software should be structured and how users will interact with it.
4. Development
This is where the software is actually built. It is the building blocks that you would later come back to if any improvements or changes need to occur after going through the next stages.
5. Testing
The software is tested to identify problems and make sure it behaves as expected.
6. Deployment
Once the software is ready, it can be released for users. It will also be monitored to check for possible user data.
7. Maintenance
The work doesn’t necessarily stop after deployment. Software may need bug fixes, security updates, improvements and new features.
The SDLC Isn’t Always a Straight Line
_________________________________________________________________
One of the most useful things I learned is that the Software Development Life Cycle shouldn’t necessarily be thought of as a one-way journey.
Sometimes testing reveals a problem with the design. Sometimes users provide feedback that changes the requirements. Sometimes a new requirement means going back to the planning stage.
In other words, software development can involve revisiting earlier stages of the lifecycle. This makes a lot of sense when combined with what I learned about Agile.
Software is rarely “finished” in the traditional sense. It can continue to evolve as users, businesses and technology change.
My Main Takeaway This Week
The biggest lesson I took from this phase of learning is that software development is as much about managing change and solving problems as it is about programming.
Waterfall showed me the value of structure and predictability and the issues that can occur with structured formats and their lack of flexibility.
Agile showed me the importance of flexibility and responding to change while having it’s own faults like possible issues with communication and possibly losing focus of the main project as smaller or more difficult features start to pull attention.
Scrum showed me how an Agile approach can be organised into a practical framework, this would in some places provide a fix of sorts to more major issues with the agile method on it’s own.
While looking into the SDLC helped me understand the bigger picture of how software moves from an initial idea through development, testing, deployment and ongoing maintenance.
As I continue my Level 3 Software Development journey, I am beginning to see that becoming a software developer isn’t just about learning programming languages.
It is about understanding how software is planned, built, tested, released and improved — and how developers work with other people to turn an idea into something useful.
This phase of learning has given me a much better understanding of that bigger picture, and I am looking forward to building on it in the weeks ahead.
#SoftwareDevelopment #SoftwareDeveloper #SDLC #Agile #Scrum #Waterfall #Programming #TechLearning #LearningJourney #Level3SoftwareDevelopment
