How to compare software developers based on methodology

Written by Eban Escott, Ph.D., CEO of WorkingMouse

When it comes time to choosing the right software developer or development team for your project, there is more to consider than simply comparing an hourly rate.  There are many factors that come into play, not least the choice between onshore and offshore developers.

What are the major software development methodologies?

Before software development begins a methodology needs to be agreed upon.  There are two commonly agreed upon frameworks that many software developers use.  These broadly include the Agile and Waterfall methodologies.  A methodology is a simple way of describing the software engineering framework that will be followed in order to structure, plan and control the development of a software application.

The Agile methodology attempts to minimise the risk that software developers face by breaking development into short sprints also called iterations.  An iteration usually takes between 1 and 4 weeks and can be thought of as an independent software project within the bigger project.  The reason for this is new functionality is added each sprint and requires planning, design and documentation as well as testing before release.  The aim of using Agile is to be able to release new software at the end of every iteration so that the developers can assess and re-evaluate the priorities if need be.

The Waterfall methodology is distinctly different from Agile because there are distinct goals for each pre-planned stage of development.  There are no iterations and testing during development.   In order to get to the final release stage every phase of the plan has to be completed in the order it was written.  There is a tight deadline and in theory leads to a software project being delivered on a specific date.  The aim of using Waterfall is to be able to avoid scope creep as everything is agreed upon before development begins.

Does it really matter what methodology a developer uses?

In short, yes.  A developer will tend to work by a methodology and price accordingly.  Focusing on the two main methodologies, Agile and Waterfall, it is important to understand which one is being used before development commences.  The methodology choice will ultimately determine how the software is built.  It is critical to remember that developers do not necessarily know exactly what you need, so they build what they think you need.  For this reason the backlog of requirements needs to be a very accurate representation of your needs, or the software developed could be completely useless.

What is the Waterfall Methodology?

To begin with, the Waterfall methodology is a fairly linear way to approach software development.  All requirements are scoped out in a comprehensive fashion.  The reason for this is the developer’s final software will be a direct reflection on what was agreed upon initially during the scoping phase.  The distinct phases of the Waterfall methodology are:

  • design;
  • develop;
  • test; and
  • deploy

in that order.  A project’s timeline is predetermined and at the end of development the final version of software is delivered.  It is the lack of precision in the requirements of the Waterfall methodology where software development projects ‘go off the rails’.

In terms of advantages, Waterfall allows for both customers and developers to agree upon what will be delivered, and at what cost, before any development occurs.  Therefore, the upside is that there is ‘less’ risk of scope creep.  The downside is that there is now limited flexibility in terms of altering the project’s requirements once development has begun and as such, the developer (usually) wears the risk.  This can result in a much higher cost and should only be chosen if you, as the customer, are sure about what your end users want.

What is the Agile Methodology?

The other methodology that is quite popular among developers is referred to as Agile.  There are many different forms of Agile with many different names for the participants.  This methodology allows developers to take a more iterative approach to building and delivering the software.  Iterative in this context means each sprint is planned, built, tested and released into a production environment so that User Acceptance Testing can be conducted.  Having a focus on delivering complete functional components in rapid succession both increases the emphasis on the end user and allows for components to be prioritised right from the beginning.

The advantages of Agile from a customer’s point of view are that you have an opportunity early on to see completed work, and are able to request changes to the project plan throughout the development phase.  While this may increase the cost, the developers will be able to produce an MVP (Minimum Viable Product) quickly which allows User Acceptance Testing (UATs).  This build, measure, learn style using sprints allows you get the software right before going to market.

What is the difference in the requirements documents for Agile versus Waterfall?

A requirements backlog is a list of features or technical tasks which the team maintains.  For both Agile and Waterfall these requirements are necessary and need to be sufficiently documented in order to complete a project.  The difference between the ways in which they are used by the individual methodologies is that Waterfall requires every single requirement to be recorded prior to the commencement of the project’s development whilst Agile only requires the first 2 – 3 sprints to be recorded.  As additional sprints are required, the requirements will be documented and can be altered as the project evolves.  There is no flexibility with the requirements backlog when using Waterfall.  This is something that customers would benefit from if they know exactly what they want to build and have done extensive end user research to determine that there is product market fit.  Ultimately, both methodologies work as long as they are agreed upon before development.  Switching between methodologies can create major complications and risks one or both parties being left disappointed.


The key takeaway is that before you decide on a software developer you need to confirm which methodology will be used.  It will shape the entire development of the project and directly affect the cost.  Don’t be afraid to ask the question “What methodology will you be using to develop this project?”.  It is imperative that you get a clear answer before you hire or contract out software development.  Software development is an amazing journey, made even better with the right developer.

About the Author

Eban Escott is the founder and CEO of WorkingMouse.  He has over 20 years experience working as an IT professional.  He is a strong believer in applying modern startup methodologies, such as Agile and Waterfall.  Dr Escott received his PhD from The University of Queensland in 2013.  His thesis, ‘A model-driven approach to developing and testing web applications’ was the result of his passion for improving software engineering processes.  This research underpins WorkingMouse’s Codebots platform.



© WorkingMouse Pty Ltd ACN 118 569 136 reproduced with permission.


This article is not legal advice. It is general comment only.  You are instructed not to rely on the commentary unless you have consulted one of our Lawyers to ascertain how the law applies to your particular circumstances.

Send this to a friend