Most of the programmers are struggling today with their programming life because of unbalanced working hours, increasing number of defects, late deployment etc., which impact most of the things including quality and delivery of software, personal life etc.
I was reading “extreme programming explained embrace change” by Kent Beck. I found this book to be very helpful to ease our stressful programming life, to deliver good quality software with far fever defects. Extreme programming is about changing yourself, letting your mistakes exposed and then learning from those. It’s about writing good code and following best practices. It’s about developing good relationship with your team members and customers.
The backbone of extreme programming is Values, Principles and Practices. All are linked together. Values give you a reason to apply practices. Principles give you guidelines for practices. For example:- You commit a code on github and send a pull request to merge. So here, you value code version control system. Here practices are committing code and sending pull requests. The guidelines, which you follow to commit code and send pull requests, are principles.
I won’t go into deep of XP. You would find much details in the book”extreme programming explained embrace change” by Kent Beck. However I would explain some XP practices, which are easy to follow and would be helpful in reducing your programming stress and improving quality and delivery time of software. Here are some practices:-
Improve Team Communication
Spend some time on internal team communication. It could be a small coffee break. Sometimes communication helps to gain knowledge and resolve defect. If you have resolved any critical defect, you can discuss the solution with your team members and that solution might help them as well if they are stuck with similar kind of issue.
Follow Simplest solution
Always try to implement simplest solution as much as possible. The purpose of this practice to focus on only today’s needs. We can add extra functionality later. We should design and code to cater need for today’s scenario. A simple design with very simple code could be easily understood by other team members.
Fix the root cause of defect
Sometimes programmers just brush off defects, but this is not good for everyone. There might be chances that defect could resurface again. This could also result in loosing customer confidence. A programmer must always perform root cause analysis of any defect. This will help in their learning and building a system with fever defects.
Respect
A programmer should respect project and other team members. Respect doesn’t mean saying sir/madam all the time. It includes
1) When you commit or merge code, you should make sure, it won’t break built, compilation failure or failure of existing unit test-case. That could cause issues to other team members.
2) While talking to other team member, always assume that the person, you are talking, has best intention. It will also help to avoid lot of miscommunication.
3) No one in the team should be feel ignored. Every team member should feel accountable for success/failure of the project.
Development with whole team
There should be enough space available, where whole team can sit together and develop. It would help to communicate or discuss with other team members about any defect/functionality. It can also help in the productivity. You can spend either half of the day or limit work hours for this activity, so that people can also get time for their privacy needs such as smoking, chatting.
Team with all the required skill
In the above point, I mentioned whole team. Whole team means team with all the necessary skills, which are required for the project. For example: If there is a need for designer, there should be a designer. When there is no need, he/she should not be part of the team.
Never do fractional programming
Fractional programming means doing 50% on this project and 50% on the other. So much time and efforts are wasted while switching task and doing communication with other team member. This is also dangerous for the productivity. Customer wants the benefit of whole team. So one should be dedicate to only one project at a time.
Informative Workspace
Keep the workspace informative with help of graph chart, diagrams etc. You can use white board, where you can write your yesterday’s task, what you will do today and plan for tomorrow with estimates.
Code only in productive hours
I saw many programmers doing late night work, burning themselves, avoiding lunch/dinner and spending weekends. This would neither be productive nor the good for you and your team members. According to XP, a programmer should dedicate a small amount of time for coding and manage that time better. You can declare only two hours for coding. But in those two hours, you should only be doing coding, turn off phone, email/slack notification or add a “Do Not Disturb” tag on back of the chair. If you are sick or suffering from any personal issue, you should take leave. Doing so, you will respect other team members by speed up tasks.
Pair Programming
It is one of the important practice of XP. Pair programming means when two person are sitting together on a single machine. Pair programming has its own rules. If one person is coding, other one can review simultaneously and share his feedback. Pair programming should make sense. If there is a very small code change, pair programming won’t help much.
I tried to explain few important aspects of extreme programming. Since it’s very extensive subject to be discussed, please get some time to go through “extreme programming explained embrace change” by Kent Beck. I am sure it will surely add values to your extreme programming skills.
Nice blog to read. Thanks @ayushmishra2005