In this first installment of “Think about it,” I’ll tell you about something that happened to me as I was leaving my postgraduate course. I got a ride, and in the car a few students and professors continued discussing software best practices and RUP, which had been a subtopic in a software engineering talk. But without any technical arguments, they simply equated XP (Extreme Programming) with a hack, and even mentioned POG (programming-oriented-gambiarra).
As you can see, I have not included—and will not include—a link to pages explaining POG, because these are practices that are genuinely useless to a developer. But if you want to read about them for distraction or amusement, without treating them as a professional reference, you can search for the term on Google or Wikipedia.
Here is the definition of gambiarra cited by Rodrigo in his master’s dissertation:
“Gambiarra is the informal name for the procedure needed to configure an improvised artifact. The term is also often used to refer to the artifact itself.”
He also shows that this attitude should be understood as immediate, projective reasoning, determined by momentary circumstances, and culturally associated with the so-called Brazilian knack for improvisation.
I know what you’re wondering now: what does this have to do with XP?
Exactly what you thought! Absolutely nothing! XP is not improvisation, it is not a workaround, and it is definitely not a hack!
XP is a set of established practices intended to make software development more dynamic and incremental, with faster feedback, frequent changes, and active participation by the customer and users.
Its principles differ from those of more traditional practices because of the bottleneck created by excessive documentation and the difficulty of effective communication among the many people responsible for development. The result was often software delivered past its deadline and, all too often, a dissatisfied customer who, whether they said it aloud or merely thought it, would say: “That’s not what I wanted at all!”
Instead of dividing the team into separate roles—analyst, project manager, programmers, and so on—each member should be involved in the entire software development process: the meeting to decide what needs to be done, analysis to decide how it will be done, writing the test (TDD), and creating the selected module (an interface the user can try out and give feedback on). Keeping professionals informed about the whole process makes them very good at the specific creative act of programming while also giving them an overall perspective. This approach was inspired by Toyota’s methodology.
In the 1940s, Toyota needed to find ways to produce cars more quickly and with better quality while reducing costs. That is how it created what is known as Lean Production and refined it over decades; it is now known as just in time.
The fifth and seventh basic principles of the method are called “Empower the Team” and “See the Whole,” respectively. They are based on the idea that improving quality as much as possible requires getting the details right, and the people best suited to do that are those who actually perform the work—the people who, as we say, “get their hands dirty.” This goes hand in hand with constantly checking the whole: the final product must always matter more than any one component. As a result, each team member needs to go beyond their specialty and make decisions at the analysis and design levels, too.
Using these and other principles, Toyota reached a historic and symbolic milestone in April 2007, surpassing General Motors (GM) in worldwide car sales.
In his talk about XP, using the Treina Tom interface, Vinícius Teles showed a slide with a photo of Jack Järkvik, Ericsson’s vice president in Sweden, talking about how much money the company made over the years. A lot of money—really a lot! He also said that Jack pointed to the screen showing XP practices and said that everything being presented at the XP event was something they had already been using since the 1980s, and that this was consequently what had made them so much money.
So I ask those who still think XP is a hack to ask the leaders of Toyota and Ericsson whether their processes are hacks. I think they would get a very interesting answer. Here is one more tip: Vinícius said that the Ericsson vice president had seemed rather arrogant during his talk. Below is his photo, so you can get an idea:
I still believe strongly in freedom of expression, because that is exactly how I came into contact with new ideas. I also trust that students, professionals, and curious people will know how to distinguish a superficial, worthless remark from a better-reasoned one. After all, one of academia’s principles is to pass on scientific and philosophical concepts so citizens have more tools at their disposal than just common sense—which is important, but on its own is not enough to master a problem domain in a production environment.
But a professional might ask me: RUP has worked well in institutions such as Banco do Nordeste, and it is not an agile methodology.
I am not disparaging any other process here. I am simply stating, technically and historically, that XP is a valid, established process that has delivered good results, including at large companies. I believe students should encounter several approaches and, in the end, decide which one best matches their expectations and principles. I will say again that XP’s streamlined communication process makes the environment more dynamic, less tedious, and healthier for a generation that does not identify much with excessive hierarchy and bureaucratic processes—for people who want to prioritize the software rather than an excess of documents.
There is always a question about documentation: does XP use it or not? Yes, it does, but as a supplement and only as much as necessary, after an iteration is complete and some result (the software interface) has been shown to the customer, who confirms that it is really what they are looking for. A well-written class can be easily understood by an experienced developer and can itself be considered a document that never becomes outdated. We also know that, depending on the software’s complexity, it can be important to supplement this with, for example, a class diagram or an ER diagram, to get a clear overview of the system. These are used first for planning (trying to find the best combinations at a higher level of abstraction) and consequently as documentation. Automated TDD tests (Test-Driven Development) are another part of the documentation. In the specific case of unit tests, they are routines that check whether a given class will function properly, providing greater assurance and helping prevent failures. To protect the integrity of these practices, which focus “more on software and less on documents,” XP uses refactoring to make the code simpler and simpler without changing its behavior, and pair programming, which reduces the errors a programmer might make alone and spreads knowledge of the software so that it becomes the responsibility of every team member, not just isolated individuals.
To wrap up, XP practices should not be treated as mandatory requirements for success. They can and should be adapted to the context, and they may or may not be used together. They should be treated as principles that can be improved.
That’s all for now. Until the next “Think about it.” To learn more about XP and agile methodologies, visit these links: