What are the causes for the failure of traditional planning approach?

The traditional planning approaches does not always lead to very satisfactory results.

Causes for Planning Failure

Cause #1: Planning is done by activity and not feature
- The traditional approaches to planning focus on activity completion rather than on delivery of features.
- Activity based plans generally lead to projects that overrun their schedules.
- Hence, quality is reduced.

Cause #2: Activities do not finish early
Cause #3: Lateness is passed down the schedule
- Traditional approaches being activity based, their main focus is to focus on dependencies between activities.
- Testing will start late if anything goes worse than planned according to traditional approach.
- Testing will start early if everything goes better than planned.

Ways to avoid late start of testing are:
1. User interface coding finishes late.
2. Middle tier coding takes longer than planned and finishes late.
3. Middle tier coding starts late as tables adding to database finishes late.
4. Tester is not available.

Cause #4: Activities are not independent
- Activities are independent if duration of one activity does not influence the duration of another activity.
- For independent activities, late finish on one activity can be offset by an early finish on another.


Cause #5: Delay caused by multitasking
- Multitasking exacts a horrible toll on productivity.
- It becomes an issue once a project starts to have some activities that finish late.
- Dependencies between activities become critical.
- For a traditionally planned project, multitasking becomes a problem for two reasons:
1. Work is assigned in advance and it is impossible to allocate work efficiently in advance.
2. It focuses on achieving high level of utilization of all individuals rather than on maintaining sufficient slack.

Cause #6: Features are not developed by priority
Cause #7: Ignoring Uncertainty
- We fail to acknowledge uncertainty in traditional approach.
- Ignore the uncertainty about product.
- Assuming initial requirement analysis will lead to complete specification of product.
- Ignoring uncertainty about how we will build the product.
- The best way to deal with uncertainty is to iterate.


After looking at the problems with traditional approaches to planning, many projects are disappointing. Planning based on activity diverts us from features and as a result, a variety of problems leads to the likelihood of delivering late against a schedule.

Volume tests - Volume Testing of Messaging systems

Volume tests are often most appropriate to messaging, batch and conversion processing type situations. In a volume test, there is often no such measure as response time. Instead, there is usually a concept of throughput. A key to effective volume testing is the identification of the relevant capacity drivers. A capacity driver is something that directly impacts on the total processing capacity. For a messaging system, a capacity driver may well be the size of messages being processed.

Most messaging systems do not interrogate the body of the messages they are processing, so varying the content of the test messages may not impact the total message throughput capacity, but significantly changing the size of the messages may have a significant effect. However, the message header may include indicators that have a very significant impact on processing efficiency. For example, a flag saying that the message need not be delivered under certain circumstances is much easier to deal with than a message with a flag saying that it must be held for delivery for as long as necessary to deliver the message, and the message must not be lost. In the former example, the message may be held in memory, but in the later example, the message must be physically written to disk multiple times.

Before conducting a meaningful test on a messaging system, the following must be known:

- the capacity drivers for the messages.
- the peak rate of messages that need to be processed, grouped by capacity driver.
- the duration of peak message activity that needs to be replicated.
- the required message processing rates.


A test can then be designed to measure the throughput of a messaging system as well as the internal messaging system metrics while that throughput rate is being processed. Such measures would typically include CPU utilization and disk activity. It is important that a test be run, at peak load, for a period of time equal to or greater than the expected production duration of peak load.