“The Agile movement proposes alternatives to traditional project management. Agile approaches are typically used in software development to help businesses respond to unpredictability.”
There are many agile methodologies for software development out there.
SCRUM, RAD, DSDM, UP, RUP and XP are some examples.
For now, I would like to talk a little bit about XP.
XP stands for Extreme Programming, it’s an agile methodology, and it groups some programming best practices I’m always trying to be aware of when coding.
Some of those best practices can be really controversial.
For example, they defend that no specification document is needed.
Many people are against this practice, but if you check, you will see that the vast majority of the existing documentation is outdated.
The advocates of XP argue that is better not to have any documentation rather than an outdated one.
An outdated documentation may lead you to mistakes that will be hard and expensive to detect and fix.
Additionally, they argue that a well written code doesn’t need any documentation or comment to be understood, because it is self-explanatory.
Wait! We are talking about Agile Methodology, aren’t we?! Exactly!
This is another controversial topic!
Some people believe that putting two people working together on the same machine is a waste of human resource and double cost.
However, it is well proven that developers working in pairs will add as much functionality as if they were coding by themselves.
Not only that, the quality of the code will be way higher, which can lead to great savings on maintenance afterwards!
There is a psychological principle called cognitive dissonance that explains humans have a natural tendency to believe that what they are writing is correct.
What? What does psychology has to do with Agile Methodology??
And the answer is: everything!
We can read many times a line of code we’ve wrote that contains a typo and don’t find any typo at all.
This little trick played by our brains can lead to huge expenses and can be avoided by having a second programmer, usually called “Navigator”.
The “Navigator” just watches the first programmer do the job for a while and then, they change their hats.
The thing is that the navigator has a complementary vision and is not affected by the cognitive dissonance of his colleague.
Isn’t it interesting?
Give it a try in your team and see for yourself!