In Agile developments, the scope line of burn-down charts should never go up unless it is a planned (removing other similarly estimated stories, or adding more resources to the team) addition of requirements to the project. If there are estimates that are bad:

1) If the wider project is believed to have incorrect estimates, then, the entire work should be re-planned, otherwise there is a huge delivery risk, i.e. The entire team having to consistently throughout the project work long hours (developer productivity is limited to a few hours a day and it is unlikely 10 hours of pair programming could work), or having unachievable velocity requirements. However, this is a benefit as this is determine within the first 2-3 iterations (hopefully they’re 2 weeks).

2) Scope line should be progressing by increasing the estimates of the stories that have lower estimates (if some estimates were wrong), but at the same time removing “Would haves” or “Could Haves”

3) It should be looked at on what was missed (e.g. consistently leaving out acceptance test scripts) for the stories to be estimated or a ‘Safety Check’ (used in retrospectives) to allow the facilitator to check if the developers will be open and honest about estimates.

In my years of experience, the most common repeat offender I’ve seen is the excessive use of IF Statements. As a result. I’ve joined the Anti-IF Campaign.

It results in code that is hard to change, maintains, and does not use composition, inheritance, or design patterns to write meaningful code. It is just a code that runs. I’ve spent hours trying to find out bugs in if statements written in butterfly form (nesting going 3-5 levels deep). Try adding a feature to an If statement at the 3rd level which goes down 5 levels. This won’t give you much confidence that it won’t have unintended side effects.

There are some examples in which it may be hard to get rid of such as Mark Needam pointed out unless some overkill solution is applied (Attributes, Validation blocks), but the other common offenders can be removed.

The disadvantages is both – processA and ProcessB will be evaluated, possibly making the process inefficient. In 2008, If method was introduced, and direct casting is not necessary. So this can be changed to:

if (expression == something), processA, ProcessB)

Scenario #3

Avoid If at the start of a method and end if near the end. If should not span the whole method.

Scenario #4

If you have nested if’s, see if there are better alternatives. This makes maintenance and manageability of the code difficult. Excessive if’s points towards procedural code, thus should be limited (but not necessarily entirely avoided).

Scenario #5

public void MethodA() {
if (condition1) // note first line is an if
{
50 lines, nesting goes down to three level
}
else if (condition2)
{
similar issue as above
}
else if (condition3)
{
similar issue as above
}
}

This is probably bad design, and could be replaced by various patterns to make life easier.

The why is interesting. “To be a fake dynamically-typed language like Ruby”, or a more honest answer – to avoid the pain when integrating with IronRuby where before 4.0, reflection had to be used to call on its members. Now with help from the DLR (Dynamic Language Runtime) pain resolved…. I wonder if there will be anything interesting in .Net 4.5

I was practicing a design problem on applying different types of gift and item-category vouchers to a shopping basket with some edge scenarios. The problem shouted out Visitor Design Pattern, which would’ve been a fantastic solution. However, there is a certain level of influence you have depending on recent experience. The key problem stood out was that the voucher should tell the shopping basket how much discount it can give based on its contents. Separating algorithms out into separate classes could lead to Anemic classes that hold information rather than serve any functionality.

As a result I read up someone’s twitter comments:

“When adding new methods to existing classes ask out loud “Is this appropriate?””

“Make abstractions at the last possible moment & only if they exist in the business, just because concepts seem similar doesn’t mean they are” (I used abstract voucher to derive concrete vouchers)

“Favour explicit code and more concrete classes over awkward abstractions and the quest for a DRY codebase ”

At the end, architecture could be anything, the key thing is to improve with refactoring and new functionality being added in.