A Brief History of Software Development Methodologies

Software development methodologies have come a long way since British computer scientist Tom Kilburn wrote the world’s very first piece of software in 1948 using eight words of working storage plus 17 words of instructions, rendering a program size of 25 words.

As software became much more complicated (Kilburn’s software took ‘only’ 52 minutes to correctly compute the greatest divisor of 2 to the power of 18) than running a single instruction or operation, so did the coding requirements.
Earlier software development methodologies borrowed many ideas from established engineering practices: Gather ideas into a design, then start the work once the design is complete.

The Waterfall Model is widely considered the oldest of the structured software development life cycle (SDLC) methodologies. Waterfall is a rigid structure that served its purpose well. That is until software engineers realized in the ‘90s that the industry was in the midst of an application development crisis.

Beginning in the ‘70s, computers started becoming mainstream in business. Almost all industries were rolling out computer technology to provide more efficient services to their customers.

Computing has since been on a relentless journey of incredibly rapid technological change, but these hardware upgrades would mean little, however, without the accompanying advent and growth of software development. Software companies mushroomed to provide clients the programs necessary to automate or improve their processes.

In the ‘90s, a troubling pattern emerged. Whenever a client ordered software based on an identified business need, developers required an average of three years to deliver the finished product. At the time, this timeframe became known as the “application development crisis" or “application delivery lag."

In the early days, the three-year waiting period was not an issue considering computers were very expensive and yearly upgrades on hardware and software were still unheard of. In the highly specialized industries, such as aerospace and defense, hardware and software systems often featured designs developed a decade or more prior.

The waiting period developed into a full-blown crisis when businesses started moving faster in the ‘90s. The three-year software development period was just not compatible with increasingly agile entities.

Many projects had to be scrapped halfway through the development process as they had become obsolete. In some cases, developers delivered programs to the client who hadn't or couldn’t find any use for them anymore.

Meanwhile, industries such as automotive and telecommunications saw technological advancements in their fields that enabled them to build better products and deliver them to market faster.

The Waterfall Model prescribes that each phase of the development cascades into the next, similar to how a waterfall flows. The model illustrates the software development process in a “linear sequential flow,” meaning that typically, the outcome of one phase acts as the input for the next, and any stage in the development process begins only if the previous step is complete. No going back. Each stage relies on information from the previous stage and has its own project plan.

Waterfall requires the complete documentation of all features and functions up to the last line of code. Developers will need to figure out the exact parameters of the software’s functions and then set timetables and distribute team assignments. Project managers draft Gantt charts of all the processes, steps, and dependencies. They also finalize costs and schedules.

The Waterfall Model remains a defined, structured, and highly detailed methodology that follows seven development stages:

1. Specification – The client defines the business need and the desired output.
2. Design – The software’s specifications are laid out and documented. Only the features documented at the design stage will make it to the development stage.
3. Development – The development team begins writing code according to specifications to produce the desired software.
4. Integration – The software integrates with the hardware and/or with other complementary software (OS, integrations).
5. Testing – Checks to the finished software to evaluate if it conforms and performs to specifications.
6. Installation – Delivery of the finished and tested product to the customer for installation and launching.
7. Maintenance – Part of the software agreement where the developer team remains to deal with any issues arising from software use, including updates or patches.

Waterfall’s structural rigidness is both its strength and weakness. Yes, it’s easy to understand and simple to manage, but its rigid structure means forsaking potential design upgrades during the development stage.

This model doesn’t work well if flexibility is needed or if the project is long-term and ongoing. With little room for revisions once a stage is completed, any modifications requested during the development stage would require significant adjustments impacting both cost and time.

The big disadvantage of the Waterfall approach is that it does not allow much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-documented or thought upon in the concept stage.

Major disadvantages of the Waterfall Model:

• No working model is produced until late during the SDLC.
• Huge risk and uncertainty.
• Not recommended for long, complex, and ongoing projects.
• Difficult to measure progress within and between phases.
• No room for changing requirements.
• Clients cannot visualize the software early and only realize possible additions/improvements during testing

With computers becoming cheaper and more powerful, communications improved drastically. Communicating with clients and applying changes within days became more norm. When this happened, the Waterfall method became obsolete.

In a 1997 paper on Microsoft, MIT distinguished professor of management Michael A. Cusumano and coauthor Richard W. Selby aptly summed up the limitations of Waterfall. The duo wrote that Waterfall “gradually lost favor … because companies usually build better products if they can change specifications and designs, get feedback from customers, and continually test components as the products are evolving.”

Developers began to realize the value of testing out ideas for viability before producing the final product. This led to a new approach: prototype software development.

This process implied producing initial versions that can simulate the end product, all the while gathering performance metrics and user feedback. The findings serve as the basis of any improvements to the final version prior to release.

Prototyping added a vital stage to the software development lifecycle, during the design and development stages. This led to two distinct discoveries that eventually led to the development of the Agile development methodology. First, it opened software to an iterative approach. Software development became a cyclical process of prototyping, testing, analyzing, and refining the product. In addition, prototyping opened developers to the value of user-generated data. This helped test software in a multitude of user scenarios, generating critical feedback in improving performance.

As prototyping became more mainstream and the Waterfall method fast losing popularity, software developers sought an even more efficient way to bring their products to the market. In the late ‘90s, many developers and companies began experimenting with processes that allowed more flexibility with software development.

Agile development is a management framework that most contemporary software companies embraced years ago and still actively use, even though they’re not aware of it. It’s the idea of developing software in a flexible, fast-paced, and open-minded manner, with a strong focus on rapid results, efficiency, and, most importantly, the customer.

The shared frustrations of prominent programmers prompted the famous Snowbird meeting in Wasatch, Utah in February 2001.

What emerged was the Agile ‘Software Development’ Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.

This gathering of 17 thought leaders produced the “The Agile Manifesto,” highlighting the need for “an alternative to documentation driven, heavyweight software development processes.”

The short manifesto declared “valuing individuals and interactions over processes and tools,” prioritizing “working software over comprehensive documentation… customer collaboration over contract negotiation,” and “responding to change over following a plan.”

A faster and more “agile” delivery approach helped users to reap the benefits of new software faster. In addition, it helped provide the developer team rapid feedback on the software's scope and direction. In essence, the willingness to change and the capability of quick reactions are what drove developer teams to the agile methodology.

The fulcrum of Agile development, as the name suggests, is flexibility. With Agile methods, developer teams can avoid costly mistakes, save time and resources, and keep clients happy and loyal when involved in the development process. Flexibility also means that agile development allows projects to evolve naturally as the market and needs change.

In an Agile environment, the initial idea is to prepare for a short-term development cycle, complete with goals and requirements. Using smaller but tightly-knit teams, developers strive to complete an iteration as soon as possible.

This version is then released to elicit feedback from users. After collecting data from users, teams use the information to tweak the next version. This process repeats until the software takes on the form of a marketable product.

The Agile software methodology does away with pre-set rules on how to get things done. Instead, it helps break down complex projects into smaller and more manageable chunks. Agile also implies that teams should remain open to any development that can help complete the objective. As such, the agile concept represents an adaptive approach to software product development.

Agile development is considered more of a philosophy rather than a listing of set processes. As such, there are many frameworks that fall under the Agile methodology.

Among these are two of the more popular frameworks: Scrum and Kanban. The scrum is coined from the rugby term while Kanban is the Japanese word for “signboard.” While these two approaches have similarities, there are subtle differences to note.

Both Scrum and Kanban use a board that displays the progress of work. During the project cycle, team members work with three basic categories: work to be done, work in progress, and completed work.

The scrum framework breaks down development cycle time into specific work periods called sprints. Prior to the actual ‘sprint,’ a planning session convenes where tasks are allocated tasks and objectives set. The product owner will outline a prioritized product backlog and discuss with teams how to complete each backlogged item. The group collectively estimates the effort involved, which leads to a sprint forecast listing how much work can be completed from the backlog. Scrum provides the framework to help teams work together.

Sprints, which usually last two weeks, are the period where developers get to work to complete an objective as determined by project managers.

During sprints, progress is displayed on the board by showing which tasks are due for completion, which ones are in progress, and which ones are completed. Daily meetings (stand-ups) are scheduled (with the ‘sprints’ in motion) to evaluate the project’s progress.

Stand-ups are usually the best time for the team to show or demo version releases to clients prior to launch.

1. Product Owner. This person is in charge of initial planning, task allocation, and prioritization, and maintaining communication throughout the project.
2. Scrum Master. This person oversees the process during the sprint and ensures that schedules are kept and progress made.
3. Team Members. These are individual developers tasked to carry out assigned roles during the sprint.

Similar to its rugby namesake, scrum allows teams to organize themselves, adapt to changes in the environment, and learn from experience in order to improve the process.

Kanban, meanwhile, requires real-time communication of capacity and full transparency. Similar to Scrum, tasks are represented visually on a Kanban board, allowing all team members to see the status of every task at any time.

In contrast with Scrum’s defined work sprints, the Kanban methodology entails a more fluid workflow with no defined roles. Kanban emphasizes continuous development and improvement of the process. The project (or user story) doesn't set a timeframe for completing tasks. Instead, it subscribes to completing tasks based on priority.

To help focus on the deliverables and not be overwhelmed with tasks, Kanban boards usually set a limit on how many Work In Progress cards are placed on the board. New tasks can only be added to the board once earlier tasks are completed. This is in sync with its principle of continual delivery without overloading teams.

Outside of the Waterfall and Agile (including Scrum and Kanban) models, other software development methodologies are available and include the V-shaped, Iterative, Spiral, and Big Bang models. Each provides unique approaches for the various project challenges during development. Determining the right methodology depends on many factors, such as project parameters and expected outcomes.

For complex projects with a scalable growth feature, it’s recommended to consider a blend of different methodologies. Modern software demands often encompass multiple but distinct components that require specialized teams (UI/frontend, backend, connectivity, APIs, etc), and each team might require an approach distinct from the other teams. Keeping your options open is always a good idea. This includes developing custom solutions that consider various methodologies, and processes such as Agile/Waterfall shouldn’t be discounted entirely.

However, flexibility shouldn’t be limited to methodology alone. Flexibility should also reside among developer team members themselves. The choice of developer teams thus becomes a very important consideration when starting a project.

With 150+ projects delivered, Growin offers flexible software developer teams familiar with a range of software development methodologies, a crucial consideration when contemplating complex, longer-term, and ongoing software projects.

With an agile mindset, we are fast decision-makers who use reliable, scalable, and evolving technology to deliver stable and innovative IT projects and products that help clients meet their requirements.

As a human-centered company, Growin places a huge emphasis on developing the people who in turn develop technologies. We only deploy professional developer teams that take the time to understand your internal processes and to adapt to your technical and cultural background. With a customer-led development process, we are able to better support your business growth.

Our highly-skilled teams are carefully selected for their full-stack experiences with the necessary expertise to help you achieve your objectives while determining the best software development methodologies to use.

To learn more about how Growin can help grow your company, get in touch and discover how we can help you deliver your projects faster, on time, and on budget.

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –