What are the common mistakes and misunderstandings in extreme programming?

The extreme programming saw its first use in the year of 1996 when it was declared as an agile software development process. Because of its down to earth and effective rules it gradually gained wide popularity among the programmers and developers and is still on the edge of the evolution. It has been observed to be quite successful with all the kinds of companies’ whether small scale or large scale. The extreme programming facilitates the daily communication between the customers and the developers so that they are aware of the changing requirements of the customers.

The extreme programming though being so popular has always attracted controversy due to some mistakes and misunderstandings regarding its usage and concepts. In this article we are going to discuss about these common mistakes and misunderstandings regarding the extreme programming. 

Misunderstanding # 1:

- Some people have a misunderstanding regarding the flexibility of the extreme programming development process.

- They think that having an on- site customer making changes in the requirements can cause the team costly re-work and the project may expand beyond its scope and of course budget.

- The extreme programming is dependent to some extent up on an assumed unified client’s point of view so that the programmer faces no difficulty in programming rather than on documentation. 

- The same situation arises when many organizations compete to get the shares of the projects.

Misunderstanding # 2:

- One other misunderstanding regarding the extreme programming is that the requirements are considered not to be expressed as specific documents but as the automated acceptance tests. 

- In extreme programming all the requirements are not retrieved in advance like in other development processes but they are obtained one by one in successive iterations and increments. 

Misunderstanding # 3:

- Another misunderstanding is that the programmers and developers are required to work in pairs compulsorily. 

- It is not so but it depends up on the situation, budget and quality level of the software project required. 

- If the time is less for testing of the code, then it is always advisable that the programming is carried out in pairs. 

Mistake # 1:

- Another mistake that is made by the developers is that they carry out most of the activities on fly in extreme programming. 

- This follows from the idea that the simplest necessary feature is implemented first and later the complex features are added if required.

- Most of the people fear that such kind of activities can later force the team to re design the whole program. 

- Some think that having an on- site customer can cause a lot of stress to the development team and micro management may take place with the customer who basically does not have any knowledge of the technology dictating the whole development process. 

All the aspects of the extreme programming are considered to be chained together. Even if one of them gets loosen then the whole programming will be spoiled. It is believed by most of us that extreme programming is carried out by small team consisting of around 10 members! But this is not so, the size of the team can be expanded as required by the project but it should always be the minimum possible number. 

Another alternative here will be to break down the project in to smaller divisions and also divide the team as per the project divisions to keep the discipline of the extreme programming. 

Most of the people view the extreme programming as a rigid process which is absolutely wrong! The extreme programming does allow modifications in its rules but on the condition that its spirit is not violated.

 

What are common mistakes and misunderstandings in a unified process?

As it is always said “to err is human”, one may make innumerable mistakes. This truth holds good for every aspect of our lives and so for the technology also. While programming, it is obvious that some mistakes will be made but they are not intended, some mistakes might creep in without the knowledge of the programmer; other mistakes might arise due to a lack of knowledge of the programmers and the developers! 

Anything is possible. With so much complex and advanced software systems and applications to build around it is obvious for the programmers and the developers to make mistakes while programming the software because it is not the feature of human intelligence to keep of check of each and every bit of the program that is being built.

Well, this article has been focused up on the mistakes and misunderstandings that result in mistakes in a unified process. Such mistakes and misunderstandings in a development can cause severe problems in the whole development process causing further problems in the software system or application that is being built. 

What are common mistakes in unified process?

There are various mistakes that one can make while programming using the unified process. 

- The very common mistake that is done is that the complex problems might be made more complex due to lack of sufficient understanding of the methodologies that are available for programming or may be because wrong or inappropriate methodologies might have been put in to use. 

- The problem that occurs here is for adopting any software development process different people assume different values and hence it is like using a single software development process for every programmer or developer.

- For getting the appropriate solutions to the programming problems it is not necessary that the programs should be developed with the extreme agile or test driven development methodologies. See this is where the people make mistakes!

- When a software system or application can be developed using the simplest of the methodologies available then why go for the complex and the tough ones? 

- Even though the agile processes and the unified software development processes are a big step towards the advancement of the software development, it is not always that they can be extended for all sorts of softwares and applications.

- The best way to avoid much of the problems is to train the programmers and developers in information protection. It does not require months and weeks to learn about common software security mistakes and misunderstandings. 

Examples of Common Mistakes

- Suppose that during programming a file was not locked properly and there are two parts of the programs that access the same file without properly locking it. 

- Such a case can result in a race condition between the two programs that can make the file quite unstable or in a vulnerable condition. 

- Another mistake can be logging in trying many passwords in just few seconds without giving the system a proper time to check. 

- The spirit of a programmer should be as such that even if he/ she has not made the mistakes he/she should take the responsibility to correct them before they cause more harm to the software system or application. 

- The longer the time is spent on writing the programs the more you avoid the mistakes. 

What is meant by severity of a bug? What are different types of severity?

We all know what a software bug is! It is a flaw, error or mistake in the software system or application that can cause it to crash or fail. Pretty much simple!
But very few of us are actually aware about the severity of a bug i.e., how much destruction it can cause to a software system or application.

- Bugs are of course results of the mistakes made by the software programmers and developers while coding the software program.
- Sometimes incorrect compilation of the source code by the program can also cause bugs.
- A buggy program is very hard to clean.
- Bugs can have a chain reaction also i.e., one bug giving rise to another and that in turn giving rise to one more bug and so on.
- Each bug has its own level of severity that it causes to the software system or application.
- While some bugs can work out total destruction of the program, there are some bugs that do not even come in to detection.
- Some bugs can cause the program to go out of service.
- In contrast to these harmful bugs, there are other bugs which are useful such as security bugs.

WHAT IS SEVERITY OF A BUG & ITS TYPES

-"Severity can be thought of as a measure of the harm that can be caused by a bug."
- Severity is an indication of how bad or harmful a bug is.
- The higher the severity of a bug, the more priority it seeks.
- Severity of the bugs of software can sometimes be used as a measure of its overall quality.
- Severity plays a major role in deciding the priority of fixing the bug.
- It is important that the severity of the bugs is assigned in a way that is logical and easy to understand.

There are several criteria depending on which the severity of a bug is measured. Below mentioned is one of the most commonly used ranking scheme for measuring severity of bugs:

1.Severity 1 Bugs
bugs coming under this category cease the meaningful operations that are being operated by a software program or application.

2.Severity 2 Bugs
Bugs coming under this category cause the failure of the software features and functionalities. But, still the application continues to run.

3.Severity 3 Bugs
Bugs coming under this category can cause the software system or application to generate unexpected results and behave abnormally. These bugs are responsible for inconsistency of the software system.

4.Severity 4 Bugs
Bugs coming under these categories basically affect the design of a software system pr application.

COMPONENTS OF SEVERITY
Severity has two main components namely the following:

1. Impact
- It is a measure of the disruption that is caused to the users when they encounter a bug while working.
- There is a certain level to which there is an interference with the user performing a task.
- Even the impact is classified in to various levels.

2. Visibility
- It is the measure of the probability of encountering the bug in future or we can say that it is measure of the closeness of a bug to the execution path.
- It is the frequency of the occurrence of a bug.

The severity is calculated as the product of both the impact as well as visibility. A measure of perceived quality and usefulness of the software product is given by the severity. Therefore it would not be wrong to say that the severity provides an overall measure of the quality of the software system or application.

What are different tips to estimate testing time?

Time is a very important factor when it comes to the success of any matter. Therefore, timing plays a great role in the successful completion of a software project. It would not be wrong to say that the time estimation like other aspects of the software engineering forms an equally important part of the whole software development cycle.

BENEFITS OF KEEPING TIME ESTIMATION

- Keeping time estimation before the start of the software project keeps the whole development cycle on track.
- This doesn’t let your time get wasted.
- Since, there is a time limit; you have to complete the project within that time period.
- Furthermore, if you complete your projects on time, your clients will be impressed and your reputation will build up which in turn will fetch you more projects.
- An experienced software developer might be able to make better time estimations as compared to the one who is fresh in the industry.
- One who has worked up on various different software projects certainly must be having an idea of the time that will be taken up by the testing process.

TIPS FOR ESTIMATING TESTING TIME ARE:
Testing time cannot be estimated blindly. It should be done accurately and it should be realistic.

1. BUFFER TIME
- Your time estimation should involve some buffer time.
- But, keep in mind that it should be realistic.
- The role of the buffer is to help in case you have an unexpected delay in the software testing process.
- This buffer time accounts for the lost time.
- Apart from providing time for coping up with delays, a buffer also helps in providing the maximum coverage for the testing processes.

2. TIME TAKEN BY BUG CYCLE
- Never forget that this time estimation also includes the time that will be taken up by the bug cycle.
- You may estimate some time for a cycle, but remember that the actual cycle can very well require much more time.
- This problem should be avoided.
- As we all know that the testing process depends on the structure and design of the program.
- The more good the structure and design is, less will it take time.
- If the structure of the program itself is not good then more and more time will be required to fix the subsequent problems and this leads to the over run of the time estimation.

3. INCLUDE UNEXPECTED LEAVES
- The estimated testing time should also have a place for the unexpected leaves.
- Some members of the software development may require a leave until the completion of the project.
- This will help to keep your testing time estimation realistic.

4. AVAILABILITY OF RESOURCES
- You should keep in mind the availability of the resources for the time period within which you have to complete your project.
- If in case you get short of any of the resources you can update your testing time estimations accordingly.
- This is another measure to keep your time estimation realistic.

5. COMPARISON BETWEEN OLDER & NEWER VERSION OF SOFTWARE
- You can sometimes compare this software version with its older version for the test outputs.
- This will save your precious time.
- This is termed as parallel testing.
- Based on the testing time estimation of the older version you can decide time estimation for the upcoming version.

6.COUNT YOUR MISTAKE & REVIEW
- It is a universal fact that everybody makes mistakes.
- So, there is possibility that you may make some mistake while estimating the testing time.
- So don’t forget to review it once and make any changes if required.
- Always keep in mind that changing testing time estimations can have a bad effect on your reputation.
- So don’t make changes unless very much required.

7. COUNT YOUR EXPERIENCE
- You can very well employ your past experience to make wise time estimations.

8. EVALUATE YOUR TEAM EFFICIENCY
Know the work efficiency of your team members.