IT Scene and Changing Trends from an Indian Perspective

Udayan Banerjee

Subscribe to Udayan Banerjee: eMailAlertsEmail Alerts
Get Udayan Banerjee: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Virtualization Magazine, SOA & WOA Magazine, Java Developer Magazine, Microsoft Developer, CIO/CTO Update

CIO/CTO Update: Blog Feed Post

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

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.

Four 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.

Related Articles:

Simplicity: A New Model

Simplicity Is Highly Overrated

Read the original blog entry...

More Stories By Udayan Banerjee

Udayan Banerjee is CTO at NIIT Technologies Ltd, an IT industry veteran with more than 30 years' experience. He blogs at http://setandbma.wordpress.com.
The blog focuses on emerging technologies like cloud computing, mobile computing, social media aka web 2.0 etc. It also contains stuff about agile methodology and trends in architecture. It is a world view seen through the lens of a software service provider based out of Bangalore and serving clients across the world. The focus is mostly on...

  • Keep the hype out and project a realistic picture
  • Uncover trends not very apparent
  • Draw conclusion from real life experience
  • Point out fallacy & discrepancy when I see them
  • Talk about trends which I find interesting
Google