Haja’s Blog

IMG_0129, originally uploaded by haja_maideen_m.

Bought this new HTC touch recently, can not wait that long for iPhone.

• From my experience, don’t follow XP (Extreme Programming) methodology for bigger ERP kind of product development; follow this for smaller teams (~20 members) and 2 to 6 months project.
• If the team is geographically dispersed, don’t even go near this methodology.
• Have real customer, no proxy customer.  Lack of proper requirement engineering leaves customer feedback only choice for validating the requirement to the implementation, so customer role is key to team success.
• Don’t fake, pair programming. I observed many times one team member taking rest (or do something else) while other member coding, this defeat the purpose of getting quality output by pairing developers. Also pairing for non programming tasks (like server builds etc) not going to help, so avoid these.

1. Light weight software development methodology for small to medium sized projects.
No need to follow complex processes and filling tons of documents for anything, save the precious time the mighty programmers have and relieve them from pain of documentation and Bureaucracy.

2. Work elbow-to-elbow with customer in all software development phases (Planning, developing, deploying).
Review and receive feedback from customer all the time, customer need to be aware of the state of the application any given point of time.

3. Release well tested software very frequently.
 Shorter release cycles (weekly/daily/monthly), follow test driven development, automate your testing and deployment.

4. Follow Iterative software development cycles.
 Start with what ever information available, refine and rewrite as things become clear in an iterative way.

6. Work very closely with the team, write code in pairs.
Two person, one computer, one task, quality of the work product will be better in the long run (lesser bug because two brains working on single task). If possible have bigger cubes, and have every one sitting closely together (including the customer).

7. Continuously improve the code to make it better.
 Look for even simpler refinement in past release’s code, and continuously fine tune it.

8. Keep everything very simple and clear; keep it running all the time.
No need for detailed architectural design before starting coding, make it simple, show the result to customer, refine it in later iterations if needed.

9. Have fun.
Following xTreme programming is not that easy when compared to well planned, documented ‘Other’ methodologies, so do all the above without killing yourself and have fun.

10. Retrospect after each iteration.
 Correct the mistakes, do course correction, and become better ‘extreme programming team’, after each iteration.