Phasing your software project

Wed, 21 Jan 2009 21:45:59 GMT

I've just been putting some slides together for my Pitfalls for new software architects talk and it got me thinking about how different project teams approach the phasing of their software development projects. I'm a proponent of getting the risky stuff out of the way first so I can prove that the architecture will work, whereas others like to tackle the easy aspects first because it's a great way to motivate the team and tends to show more visible progress.

There's no right or wrong way to approach this; and much of it will depend on the project context, deadlines, availability of resources, etc. Having said that, it's worth understanding the trade-offs that you're making by tackling the easy stuff first. As an example, I've seen a few projects that have started by adopting a phased approach where they delivered read-only parts of their system during the initial phases with a view to layering on the transactional parts afterwards. I've already touched upon the rationale for doing this (team motivation and visible progress), but let's consider some of the trade-offs.

First of all, the transactional aspects of any software system tend to be the more complex to design and build, so you're deferring the features that are potentially the riskiest until later on in the project. Okay, so you can still prove parts of the overall architecture, but comprehensively testing the architecture requires that you test the significant data-flows in all directions (i.e. in and out of the system).

On a less abstract level, focussing on the read-only features probably means that you'll come up with a collection of architectural patterns that will need revisiting when it becomes time to layer on the transactional features. For example, will a read-only driven codebase easily support concepts such as transactions, locking, data serialisation back down through the architectural tiers, exception handling and so on.

Sometimes the rate of visible progress at the start of a project can set expectations that progress for the rest of the project will continue at the same rate, both for the project sponsors/stakeholders and for the project team themselves. Unfortunately though, often this isn't the case and tackling the easy stuff first can lead to substantial rework at later stages in the project. Software projects can be approached and phased in a number of ways but you need to be sure that you understand the trade-offs. Taking the wrong approach can hurt your architecture and your deadlines.

Coding the Architecture - methodology tag

Phasing your software project