Work

Home | Work | Play | Photos | Contact | About

Approaches to Developing Software

Home > Work > Approaches to Developing Software

Introduction

Someone starts a career writing software. After 10 years or so, she finds that doing certain things seems to yield better results than not doing them, or doing other things. She writes them down, so that others starting a career writing software can shortcut their learning.

That's what a methodology is. It's a blueprint of the things that should be done to ensure success. There are many methodologies. Some people think that some work better than others. Other people think none of them work. Some get a little more nuanced, and think that doing agile badly is cheaper than doing waterfall badly. This is quixotic - wasted time is wasted time, and technical debt (agile done badly) is still technical debt (Waterfall done badly).

Today methodologies fall roughly into these two categories - Waterfall or agile. Waterfall is seen as slow, cumbersome and expensive. Agile is seen as fast, nimble and cheap. And yet neither quite measure up to their claims.

I'm going to briefly describe and then compare the strengths and weaknesses of both. I'll finish by pointing out that success depends on the experience of the team and their techniques (good practices), rather than choice of any methodology.

Let's start with Waterfall:

Waterfall

Waterfall is composed of an ordered set of phases. Phases cascade down what many believe are the essential components of the software development process. The order of these phases is arranged to yield the greatest chance of success.

Waterfall process

Weaknesses

All of these weaknesses pale in comparison to this one:

Strengths

Whether we want to admit it or not, Waterfall has exceedingly compelling advantages:

Agile

In agile, activities are bound to other activities, and not to phases. Phases seem to be done concurrently. Agile is, in essence, a one-phase approach. This is why eXtreme Programming, scrum, and so on seem like undisciplined hacking. However, it’s not that at all. It is a way of developing software when not only the solution, but also the problem is unknown.

Weaknesses

Agile's weaknesses are a little more difficult to pin down. Other than a lack of context or concrete guidance, the agile manifesto contains no apparent weaknesses. This left me with my observations and experiences, and looking at specific agile methods.

Some method-specific disadvantages:

All of these weaknesses pale in comparison to this one:

Advantages

The Role of Experience

Changing context for a minute, let's talk about martial arts.

Karate is a martial art. It is also a sport, with strict rules and competitions. Krav Maga is street fighting - no rules, and no competitions. I've been doing Krav Maga for over four years, and think it's the dog's bollocks.

Saying that Krav Maga is the best is interesting. Not because it really is the best, but because that statement demonstrates two important things:

The same philosophy applies to software development processes. An experienced team using Waterfall is more likely to succeed at a project than an inexperienced team using agile processes and techniques. The reverse, of course, is also true.

Conclusion

All of the successful projects I've worked on succeeded in spite of their methodologies, rather than because of them.

Agile has no upfront design. An experienced developer anticipates downstream requirements and makes the correct choices at the start. Similarly, an experienced developer will create a prototype or proof of concept during the design phase of a Waterfall project to demonstrate his thinking, thereby reducing risk, and saving money in downstream phases.

Experienced developers, whether agile, waterfall or somewhere in-between, will write (or insist on) a written specification. It doesn't matter whether the specification consists of stories, use cases or a MoSCoW list. Because when things go wrong (experience tells us they will), specifications become the team's only sense of "truth". This is critical when a team scales.

Methodology can be helpful or harmful to development because without context, no single rule is universal. Choose a methodology that's appropriate for your sponsor, your project, the team, and your your environment.

< Back to Work | ^ Back to top


All content copyright © Michael Wittenburg 1995 to 2024. All rights reserved.
Merch (t-shirts designed by my twin)