When you’re building software, regardless of whether it’s software that will be installed on a computer (think .exe) or hosted in the cloud (think www), it’s generally a good idea to follow some methodology.

I say generally, because you could choose to ignore the methodology.

The downside of not following some methodology is that things may take you a bit longer, with likely repetition and rework.

This could be a problem when you’re creating software on a budget and within a specified timeframe; but may not be an issue if you are just starting out and teaching yourself to code.

There are tons of methodologies and various variations out there:

• Systems Development Life Cycle (SDLC) Methodology
• Waterfall (a.k.a. Traditional) Methodology
• Agile Software Development Methodology
• Rapid Application Development (RAD) Methodology
• Joint Application Development (JAD) Methodology
• Extreme Programming (XP) Methodology
• Test Driven Development
• Feature Driven Development Methodology
• Lean Development (LD) Methodology
• Rational Unified Process (RUP) Methodology
• Spiral Methodology
• Dynamic Systems Development Model Methodology
• Crystal Methods Methodology

In my experience, what generally happens is that a project team will start out with a particular methodology, but elements will fall in or out of the process as the team matures and becomes more efficient.

Generally this occurs as the risks related to the uncertainty of the requirements decrease, i.e. you can move faster as you better understand what the customer needs.

When you boil it right down, methodologies exist to use technology to help solve problems and to meet specific needs.

This is why the method that is used to develop a website or app will very much depend on the complexity of the requirements, the timeframe, budget, and the skills, distribution, and location of the team.

In consulting speak; it’s about reducing the risk of delivery, whilst ensuing ‘fit for purpose’.

Put a little methodology in that madness