Phasing your software project

Taking the wrong approach can hurt your architecture and your deadlines

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.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.



Re: Phasing your software project

There is a third way: The most important parts first.

Re: Phasing your software project

And indeed there are many other approaches: building the system tier by tier, technology by technology and so on. They all have trade-offs though.

Re: Phasing your software project

On the other hand, don't underestimate the risks around the UI design. I like to have the UI flow implemented first, and then proceed to building the functionality under it. The UI reflects the functionality from the user point of view, so building it first can get you immediate feedback from users about whether your assumptions of what they want are correct, and gives them a more concrete understanding of what you are planning to implement than they get from specs, screenshots, etc. If you build the UI after the complex and back-end work is already done, you may discover you've actually done the wrong thing on the back-end. This isn't too contradict your point, it's just that a team of 8 back-end developers and 1 UI designer may be prone to underestimate the risks around the UI and misunderstanding of user requirements, being more focused on the scary stuff at the back-end.

Re: Phasing your software project

Unfortunately the business unit of the company sponsoring your project often will dictate how the phases are carried out based upon what makes them revenue the quickest.

Re: Phasing your software project

Of course, doing the hard stuff first might give an overly pessimistic measure of progress! Perhaps a sensible just-in-time approach will give you a consistent mix of easy and hard stuff? Or perhaps it will just fall foul of doing everything "far-too-late" (as tends to be my experience of "just-in-time")?!

Starting with the UI can be great (the software exists to be used) but runs the risk of not being an appropriate trade-off between cost and worth. Users and developers can get caught up in the promise of bells and whistles that they have to try to pry out of the scope later. Something seemingly simple such as validating an address can easily be rolled into a UI with a basic mock service. Finding a real service that covers all the countries of interest may be far harder and can be extremely costly compared to the cost of implementation.

Nonetheless, my personal preference is for driving the scheduling from the user interface as this tends to be the source of requirements (and funding), but ensuring that features are considered throughout the stack before being committed to. Nurturing a culture where you can discuss a feature without it being implicitly in scope is quite difficult, though!


Add a comment Send a TrackBack