A Primer to XP

It is about finding our adult place in the larger world, finding our place in the community including the realm of business/work. It is about the process of becoming more of our best selves and in the process our best as developers. And, it is about writing great code that is really good for business.

Reading Kent Beck’s “Extreme Programming Explained” is timely. At first blush, it reads like a self-help book (how great for the new year!) — encouraging us to be bold, communicative, and respectful. On a deeper level, Beck talks about Extreme Programming (“XP”) as a flexible methodology that aims to address constraints in software development.

I was so surprised by how touchy-feely this book initially presents itself to be. Not that this is a bad thing (at all!). Beck talks about vulnerability and to not hold back our efforts and to not tie our sense of self-worth to projects. He encourages fellow developers to always do their best work. There will always be constraints and they are not excuses.

Here is an overview of characteristics that define XP:

  • Short release cycles are shaped by the release’s value-add to a business.
  • One-week iterations are focused on customer-requested features. During these iterations, the highest priority features are first implemented.
  • Comprehensive suite of automated tests to ensure quality.
  • Writing tests for functions and features.
  • Programmers are responsible for estimates and work completion.

And then there is this notion of team development. Clearly, by setting your own estimate, you have a more realistic notion of how long it takes to implement a feature. This is preferable to someone delegating a task and saying: “Finish it in X days.” You have a better understanding of your own knowledge and expertise and any constraints you may have. XP also encourages human contact (loneliness contributes to job dissatisfaction) and acclimation of new staff members by gradually providing more responsibilities. The fact that Beck expects human needs to be met through software development seems, at first glance, strange. But I think it’s also a worthwhile consideration.

What I really enjoy about reading this book is the interaction between software development and business development. Beck states that there are four variables in software development, which can be controlled at varying levels but need to made visible to all involved parties. These variables seem to require a balance; there needs to be the right amount of it.

  • Cost: Money cannot solve everything, but under-resourced projects definitely cannot help solve client’s problems.
  • Time: More time can improve quality and increase scope. Giving a project too much will hurt it since feedback from systems in production is very valuable. Too little time will affect quality.
  • Quality: Quality seems to brush up against time. In a short period of time, you can accomplish things at the expense of quality.
  • Scope: Less scope means better quality (and cheaper cost and sooner delivery!).

While there’s not a direct or simple relationship between all of these, it’s so interesting to see how they manifest in companies and business models. The notion that one can lead to great products by throwing people into the mix is nonsensical. One friend, who was interested in hiring someone to build a social media platform, asked me for an estimate. There are so many factors to consider, including the quality of the code (e.g. testing), cost, and the scope (e.g. is it an MVP?).

Among these control variables, scope is often the least considered and acknowledged. Active management of scope leads to control over cost, quality, and time. Scope also strikes me as a variable that isn’t fully determined at the onset of a project. The development of a software changes and influences its scope. Customers, after all, see a first release and will determine what they want in the subsequent releases. By refining the project scope, it will also become tolerant of future changes, which bears in mind some lessons learned from reading great books like POODR and writing code in general.

Be future-proof. Be flexible. Be modular.

Like what you read? Give Malina Tran a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.