Get a Basic Understanding of the Life Cycles of Software Development

When I decided to teach myself how to code almost four years ago I had never heard of, let alone thought about, the software development life cycle. As a brand new developer I was focused on learning the technologies that would help me land that coveted first developer job, not the nuances of how those teams operated.

When I did learn of them, I thought they would be useless to me because I considered myself a web developer not a software developer.

I've since learned that this couldn't be further from the truth and these principles/practices play a large role in my day-to-day activities (whether I realize it or not).

I'm fortunate enough to see how the code I write, the features I build, and the bugs I inadvertently introduce (more than I care to admit) affect the end user and their experience. That experience has helped shape how I think about the process of building products and solving problems for my users.

I've had some time to think about the differences (and similarities) each of these approaches offer. At their core, each is focused on delivering high quality software as efficiently and as cost effectively as possible.

Professionally, I've only used one or two of these methodologies (I don't believe I've been in the industry long enough to experience them all and I have yet to have someone explicitly tell me that the team adheres to a specific methodology) but I still find value in at least a basic understanding of all of them.

I hope to give you just that after you've finished this article. This is not an in-depth examination of each life cycle but more of a broad strokes type of approach.

So, here are the software development life cycles in no particular order:

• Lean
• Agile
• Waterfall
• Iterative
• Spiral
• Dev Ops

Let's dig in to the differences and similarities of each method.

Lean

The Lean methodology relies heavily on and is comprised of seven principles. In no specific order they are:

1. Eliminate Waste
2. Amplify Learning
3. Decide As Late As Possible
4. Deliver As Fast As Possible
5. Empower The Team
6. Build Integrity
7. See/Optimize The Whole

Each principle has a specific purpose with benefits that compliment each other.

Eliminating waste (extra features, incomplete work, managerial engagements, etc) creates more value for the customer which, in turn, enhances satisfaction.

Amplifying learning allows teams to reinvest in their ability to deliver products to customers.

Deciding as late as possible refers to all major decisions, giving teams an option based or a set based approach. This allows teams to gather facts rather than opinions to help influence decisions when made.

Delivering as fast as possible is self explanatory - build the product as quickly as possible to deliver it to customers for evaluation/iteration.

In a typical scenario, the managers dole out assignments/work to the developers. In the Lean methodology developers "teach" managers how to listen to the "people in the trenches" thus influencing the decisions/choices of management.

This helps teams feel more empowered to speak up about ides and solutions.

Making integrity a rule instead of an exception means that the customer is confident in the system being built. The customer knows the system is being built to withstand the appropriate amount of growth and "stretching" if need be.

I like to think of the integrity part along the same lines as sitting in a chair. When you sit in the chair you believe it was constructed with the best material that will hold you up every time you sit in it for the life of the chair. The customer needs to that same confidence in the product being built.

Lastly, seeing and optimizing the whole refers to the entirety of the system being built. By optimizing for the whole we look at software not as a sum of many components, but as one large entity that is optimized for efficiency.

This means that during development, the product is broken into manageable pieces and that inadvertent bugs are not only discovered but resolved swiftly.

Agile

This is the "fail fast" approach to building software.

It places emphasis on small, incremental releases with on-going release cycles. With each iteration teams strive to identify and address small issues before they become big problems.

This also means that the teams must engage stakeholders (people/organizations that the code can ultimately affect such as managers, technical leads, CTOs, and customers) to get their feedback.

If you're a freelance, your stakeholder(s) would be your customers - ultimately you need to ensure their satisfaction with the work before moving on.

Agile is technically an offshoot of the Lean methodology with some notable differences - mainly it prioritizes customer satisfaction from the outset and allows teams to respond quickly to customer feedback.

Although it is beyond the purview of this article, there is another more complex framework within Agile that is called SCRUM. This methodology is used for large, extremely complex projects and has even been used outside of software development.

Waterfall

The waterfall methodology is, by most accounts, the oldest one in the list. It was never meant to be a model for software development and got its start in the construction and manufacturing worlds.

This approach is simple in its structure - finish all parts of a phase before moving on to the next phase with more momentum building towards the project finish as stages are completed. Each stage's beginning (except for the first) and completion is contingent on the previous stage's completion/transfer of information.

Under the waterfall approach each stage has its own rigid project plan that finishes off with testing for previously completed work. It should be noted that this approach is not recommended for larger/longer lasting projects because of the aforementioned rigidity.

Think about the genesis of this methodology and you'll understand it more. It came from the construction/manufacturing world where it is common to complete one phase at a time. During the building of a house you wouldn't start putting in the plumbing before the frame has been put up.

That's not the way software development works generally. As we all know it sometimes becomes necessary to revisit a phase that was previously thought to be finished.

Iterative

This is known as the "repetitive approach" or the "make it better the next go around" approach because of the different opportunities it provides to improve the product with each cycle iteration.

I'm biased (as we all are :D) but this happens to be my favorite life cycle for development. I believe it works best for my current situation both in my freelance and career path because it allows me to constantly "move forward while making things better"

With the iterative approach, teams implement a solution, test that solution, evaluate its effectiveness/throughput, and then pinpoint further areas for improvement. This happens for each cycle (iteration) of the development process.

With each version released comes another iteration until the final product is completed and ready for rollout to users.

One of the great features of the iterative approach is you and your team get a working version of software early on in the development process. This can be especially useful to show to stakeholders to gauge their response/feedback.

One of the big drawbacks to this approach is it can consume a large amount of resources very quickly. Imagine all of the people, hours, bug fixes and wages that go into each iteration of the development cycle and you'll get a good picture of the resource usage.

Within this approach is a subset of principles developed by Rational Software Corporation (bought by IBM) called the Rational Unified Process (R.U.P.) which consists of 4 phases:

• Inception
• Elaboration
• Construction
• Transition (product release)

This set of principles is meant to be flexible and tailored to the needs of each team using it.

Spiral

The spiral methodology is likely the most flexible out of the six. It's a methodology built on risks - identifying and negating them. Risk (identification & aversion) drives every decision in this model. It is broken into four sub-phases:

• Planning (objectives)
• Risk Analysis (identify possible roadblocks)
• Develop & Test (current & next version)
• Evaluation (review of current phase & plan for next phase)

Each iteration of each phase begins with planning for the next phase. This way potential risks are identified before they are encountered. This also allows for a plan of action when said risks arise.

During phases teams also work to mitigate these risks and their impact on future iterations of the spiral development.

As the development process continues, each of these four sub-phases is repeated in spiral fashion. This allows for multiple rounds of refinement for each sub-phase until completion.

Dev Ops

If you do a quick search, you will find no shortage of information on this development life cycle method. It is the new kid on the block that brings software development and information-technology operations teams into the same fold.

These teams work in conjunction to provide small, but impactful, updates to products that come at a frequent pace. In turn, this creates a continuous feedback and improvement loop that drives development.

This particular methodology is known for automating the manual parts of development as well (think deployment).

The overall goal of this methodology is, like most others, the shorten the development life cycle and provide quality products.

One of the drawbacks to this methodology is the significant mindset and culture changes within an organization. Teams that may have been accustomed to working on many things find their tasks narrowed to only one or two.

For example, a general purpose developer may find he or she is now being tasked with only the testing portion or the end-user experience portion.

Bringing It All Home

I hope you can now see the importance and the benefits of each of these methodologies. Each of these possess their own strengths and weaknesses.

They are, at their most basic level, a set of guidelines and principles that seek to deliver high quality, efficient work to stakeholders.

When I first started learning to code I didn't have a mentor. By sharing what I've learned I hope to those who are learning to code when/where they can.

I want to share as much information and experience as I possibly can with other developers. If you are teaching yourself to code or if you're a seasoned developer I hope this article helps, even if in a small way.

---

Check out my blog where I frequently post articles about web development.

While you're there why not sign up for my newsletter? You can do that at the top right of the main blog page. I like to send out interesting articles (mine and others), resources, and tools for developers every now and then.

If you have questions about this article or just in general my DMs are open -- come say hi on Twitter or any of my other social media accounts which you can find below the newsletter sign up on the main page or on my profile here :)

Have an awesome day and happy coding, friend!