eXtreme Programming


eXtreme Programming (XP)


The 90’s was the stage for a revolution on the software development processes and methodologies. A cry for help against the Waterfall methodology, the micro-management processes and the extreme burocracy that made software development slow and low-productive. Some years before SCRUM was blueprinted. The Agile Software Development Manifest would be born in 2001, from the work of Jeff Sutherland, Ken Schwaber and Alistair Cockburn. But this subject will take another article.

Year 1996

Kent Beck, a software engineer that would subscribe the Agile manifest, creates the eXtreme Programming (XP) methodology – designation supported because it is a methodology in which their processes are taken to the extreme.

Basic principles like fast feedback, simple design, incremental changes, embracing changes and high quality work are defend by the five XP’s core activities:

  • Planning
  • Management
  • Design
  • Coding
  • Testing

I consider those processes inherent the last two activities are of extreme value for the quality of the developed code and an important tool for the health of a software development team (notice: the health within a team demands more tools that will be addressed in separate articles).

My talk – easing a hurricane called TEAM – was based on those last two activities.

I will publish a collection of articles about those rules:

  1. Standards
  2. Test-Driven Development
  3. Code Review
  4. Pair Programming
  5. Continuous Integration


Until then, happy coding.

easing a hurricane called TEAM

Meetup WordPress Porto

I had the pleasure to attend the WordPress Oporto’s Meetup. A group of geeks that get together monthly, uninterrupted for 4 years and counting. Travelling to the beautiful city of Oporto is always a pleasure, even if the distance from Lisbon goes past 300km.

easing a hurricane called TEAM

My presentation’s title. This talk starts with a brief travel on some moments of my career as a software developer. With some much needed passages on some “dramas”, which without those, I wasn’t what I am today. Those moments also enabled me to connect with some of the best professionals in the field. Some, I have the pleasure to call friends nowadays.

With them I learned what SCRUM and eXtreme Programming was and, the real importance of a CTO as a human being.

Years gone by, I see myself in that place, leading a software development team in a company that permits the usage of some of those eXtreme Programming best practices.

The second half of my talk goes on those best practices (coding standards, code review, test-driven development, continuous integration, continuous delivery), what they do daily to my team and for my team.

Next November 2nd I will have the opportunity to revisit this presentation, now at Lisbon in the change.log meetup.

Hope to catch you there.

Back to the beginning – Murphy’s Law

blacksmith’s house, wooden skewer

In Portugal we have this proverb. As much as I hear this, I will never internalize it properly.

In our field we have one, and only one certainty – What might go wrong, will go wrong.

Is there a developer that never heard of Murphy’s Law? Or that, in a specific sensitive moment, wished with all his body that Murphy could not find him?

I decided to delete, from my hosting, all my ancient projects’ databases. Playing by the book, I made backups in first hand and DROP DATABASE ...

I deleted all databases, except two. I only have two projects in my hosting, my blog and my brother’s blog. I watched in awe an error connecting to database when I tried to access both blogs.

“Ok, I probably mistakenly switched names. Will restore them with my backups.”, so I thought. “Evil” Murphy found me while I was performing the backup operation, because those files were corrupted.

I bet that even you think “that only happens to others”. Yeah, I think the same always, but this time I’m screwed. Let’s start this blog thing from scratch.