Are Large Software Projects like Eating an Elephant?


How do you eat an elephant? Simple – cut it into small pieces at eat one piece at a time.

BUT…

…is it really that simple?

When you have a large software project it is too simplistic to assume that all you need to do is to decompose the problem to individual manageable chunk which can be handled by one scrum team and then continuously keep integrating the code produced by the teams. Keep doing this and your software would be ready.

4 Assumptions you make while splitting a problem

In agile we call each chunk a user story. There is an underlying belief that it is possible to take one story at a time and code it into the application. The design of the application would emerge and the architecture of the application would evolve. But for that to happen the following assumptions must be valid:

Granularity of the decomposition: Each story is not too large – one person code it within a couple of weeks.

Loose coupling: Each story in not too interconnected with the rest of the already developed application – the code can be tested without too much complication.

Ability to iterate: Every story can be plugged in easily – it does not necessitate too much change in the existing code base – it does not create too many regression error.

Minimum emergent behavior: The impact of adding a story is predictable – when a new story is added then there is no unpredictable change in the behavior of the application.

There is no guarantee that this can be achieved for every problem. There is no scientific method which can be applied.

However, experience teaches us that a good architecture can enable this process.

The best way to arrive at a good architecture is to find an expert who has solved a similar problem and has learned the hard way what not to do!

Such a person can make the problem as simple as possible but not simpler.

What if you cannot find such a person?

Then you will need to go through architectural cycles to arrive at the right architecture before user stories can be taken up.

You also need to keep in mind that any architectural decision once taken cannot be changed easily. It would involve too much rework. So, you should defer some of the architectural decision to the last responsible time.

Udayan Banerjee on Google+

Related Articles:

Simplicity: A New Model

Simplicity Is Highly Overrated

About these ads
Comments
2 Responses to “Are Large Software Projects like Eating an Elephant?”
  1. Gene Hughson says:

    Great post. In addition to the four assumptions you list, devotees of unguided emergence make one other – that there are no conflicts between the requirements of the various stakeholders. For any but the most trivial of systems, all of these assumptions are highly unlikely.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 994 other followers

%d bloggers like this: