The longer your application exists and being actively used, it will probably change as users want features added or changed. Faced with this, most developers will try to design application for the future changes. We may start writing code that is not needed  but we write it anyway to make it future proof. We cannot exactly know how our program will evolve over time and all the extra code we write may become unusable.

Another mistake made by developers is writing the code that is rigid in structure and not easy to change. It makes sense to spend some time during the design phase and pay special attention to code maintainability. Most programmers will end up maintaining code written by someone else and it is a nightmare to maintain badly designed code.

We may also be inclined to over engineer and be too generic, thinking that we can make any future changes easily for all possible situations. You can end up writing a lot of unnecessary code to be generic. It is perfectly fine to spend time designing a good solution but if you feel that your design is making things more complex than they need to be, you are probably over engineering.

This is where Agile method of incremental development and design can help. Agile development requires less time and effort by designing system piece by piece instead of designing the entire system upfront. We can easily update design with every iteration and add new features.

If you are a small software development team or developing open source software, you can use Rational Team Concert for free. Ten developer license is free or professional version is free for approved open source projects.

Rational Team Concert will increase your team productivity by simplifying team related operations, work item tracking, source control, planning, and much more. Here is a list of some features:

Developers new to Agile development often find story point estimation confusing.  Stories in Agile development are relatively sized to each other and serve as a point based system to measure our progress. Story points are not measured in hours, days or weeks. Important concept to understand here is that the amount of work a team can deliver over a certain calendar time can be different for different teams and is called velocity.

So how do you decide what is a 3 point story versus a 13 point story? In my own experience, if you can estimate a simple story which is estimated to be a two point story, you can then reference this story as a baseline.  As you progress through the project, you can learn from your past estimations and tweak story point estimates.

Another idea is to use logical time slots for story estimation. For example a small modification can be done in 10 to 15 minutes, so we can allocate 1 hour time slot. If some enhancement is going to take 4 or more hours then we can allocate a time slot of 1 day. One very important thing to keep in mind is that story points are estimation of effort not complexity.