Tag Archives: agile

October 14, 2008

Podcasts!

By Paulo "JCranky" Siqueira

Do you know what podcasts are? If not, shame on you!

Podcasts are one of the best things invented in the last few years. And I really mean it. Podcasts are like radio shows, but you can download them, put in your mp3 player (it doesn’t have to be an iPod), and listen anytime you want. Actually, I use my mobile phone as a mp3 player to listen to podcasts.

Stuck on traffic? You can be learning something from a podcast while wainting to get home (or work). Or you can liston to something nice while doing the dishes… Or whanever you can think of.

So, bellow are a few ones I listen to all the time. But this is only the tip of the iceberg.

Java Posse – The best java podcast. Ever. Four great java developers discuss java related stuff and makes you laugh in the process.

Java Mobility Podcast – Get up to date in mobility related topics.

Agile Toolkit – So you are into Agile development? Then this podcast is a must. It features a lot of invaluable information.

Talking Metal – Relax a little bit and get some heavy-metal music news ;)

If you listen to any good podcast you think I should also listen to, please leave a comment! :)

3 comments   |  tags: , , | posted in misc

September 22, 2008

Extreme Programming Explained

By Paulo "JCranky" Siqueira

A while ago, I read the book Extreme Programming Explained – Embrace Change (2nd Edition), from Kent Beck. You can find it at amazon.com. In this post I’ll talk a little bit about this book.

In this book, Kent Beck talks about Extreme Programming (XP), going through several values, principles and practices and how this all fits together. If you already have some experience with XP and want to go further, this is an excellent book for you. But if you have no idea of what XP is, you are better off searching for a beginners book on the subject, and then coming back to this one later.

I haven’t read the first version of this book, but according to the author, several things changed. He explains a lot of those changes, and what inspired them. For example, he tells that at first, he wouldn’t consider XP for really big projects, with large teams. But today, some success stories about this kind of XP usage can be found (mainly breaking a large team into small teams).

One point to notice is that, even though the book is excelent, it isn’t its contents that I like the most. It actually is the extensive bibliography. The author lists a lot of books on XP related subjects, with short yet usefull comments on each of them. A great place to go to find a new book to read!

So, grab this book and go for more XP!

Leave a comment   |  tags: , , | posted in agile

September 7, 2008

Pair Programming

By Paulo "JCranky" Siqueira

This is the way it works: every time anyone in the team needs to develop something, whatever it is, she does it in pairs. This means that two developers sit together and work to solve the same problem. Having done it for some time, and being the coacher of a team that does it, bellow are some considerations about this subject.

With pair programming, we put in practice the principle of “Collective Code Ownership” – which means that there is no such thing as an owner for any part of the project’s code or related artifacts. This is mainly possible because the developer is not coding alone. She always (or almost always) has someone else working together on the same code, on the same functionality.

As it is said, “Two heads are better then one”. Pair programming is a practice where math doesn’t work quite well because 1 + 1 > 2 here. This means that the value created by two programmers working together is greater than the one created by each of them separately and then summed up.

Pair programming also brings a lot of other benefits, both for the project and for the developers involved. For instance, the code quality rises. It gets better design and fewer bugs that it would end up having if it was developed by a single programmer. And the code ends up getting reviewed all the time.

On the other hand, despite maybe being counter-intuitive, the productivity also rises. Two people together can find a better solution for a problem much faster. How many times have you asked for an opinion from a co-worker that helped you with that terrible problem quickly? Now imagine that you have the co-worker available to help you all the time.

For the developer, pair programming is also great because it stimulates his professional growth. With pair programming, a developer has the chance to learn from its pair’s experience. At the same time, she also has the opportunity to transmit some knowledge. This learning is much faster than reading, for example. And as they say, teaching is the better way to learn.

Unfortunately, it is not always possible to do pair programming. A few things might prevent doing it:

  • you mighty be the only one developer in a small project;
  • there might be an odd number of developers (and thus someone must stay alone);
  • or, in the worst scenario, the company won’t allow you to do it.

Or maybe any other reason I can’t think up now. Anyway, it is always worth the effort trying to do pair programming so, if you can, go for it!

3 comments   |  tags: , , | posted in agile

August 28, 2008

Value is everything

By Paulo "JCranky" Siqueira

Hello! My name is Paulo Renato, and I’ll be the writer of this blog =)

To get this started, I want to talk about value. There are several other subjects to talk about in the topics that this blog intend to cover, but value is a good start since it is what should be guiding you anyway.

In agile development, we always try to develop what brings most value to the client – this is key to any successful project. Now, the point is that the most important thing in anything you do is actually value. You just have to define what value means for each specific case.

value for the client

The client may not be beautiful, but his value is what matters.

To use this blog as an example of both what to do and what not to do, I’ll tell the history behind its creation. I’ve been planning to write a blog for a long time now. But I wanted to make something big, not just a blog. I wanted to do a lot of other possibly interesting things together. I kept planning for sometime, but I never found the time to put it all up and running. So this is what not to do: don’t try to get everything done at once when planning and / or executing your ideas, projects or whatever. If you don’t have the resources required (time, in this case), you can end up having nothing, which means no value at all.

Then I thought: “What is the most important thing for now? What would bring my potential readers the most value, right away?” In this case, the value is the information I what to put out and, also, my own satisfaction with this. The rest can come later, If there is demand and I can afford the time. So this is what to do: break the problem in smaller chunks, choose whatever would bring the most value, and do it. Leave the rest for later, and if “later” never comes, it probably means you don’t need it.

That’s it for the first post, right to the point!

Thank you for reading! And don’t forget to subscribe to the blog’s feed ;)

2 comments   |  tags: , , | posted in agile

Follow

Get every new post delivered to your Inbox.