In this blog post I interview Davide Varvello, currently working as XP coach at 7Pixel. I’ve had the pleasure to work with Davide for a couple of years during the early 2000’s in Motorola; back then, he first introduced me to the practices of eXtreme Programming and Kent Beck’s books (ironically enough, at the time we were attending an internal training to apply CMM processes to our daily job as Motorola software developers – our center in Turin would have eventually been rated at CMM level 5 years later, long after Davide had left the company).

Stefano: Can you tell our readers a bit about yourself?

Davide: I’ve been fond of computers since the 80s, I had a Commodore 64 and I loved playing and programming with my friends even if they were better than me

Next I turned my passion into a work, I've been busy with software for about 14 years wearing several hats: programmer, coach, mentor, tester.

The lovely thing about software building is that it's a creative activity like poetry or painting even if it does not follow the same goal. From an external point of view it's difficult to understand it, because a sw developer has always been seen like a guy struggling with weird numbers and cryptic algorithms, instead he is like a child with his modeling clay, taking care of it, pressing a bit, removing a bit to generate something new.

Stefano: How did you first get involved in Agile?

Davide: I think Agile is a forma mentis, it's not only linked to the will you have to improve the way of producing software, but it's the natural tendency to think how you see your life. I've always searched how to work better and I had an "Ah-ha" moment several years ago when I read an article of Bob Martin about changes in software requirements, I believe it was 1999 or 1998, anyway, Martin said requirements change 100% of the times and we, as sw engineer, should address that issue instead of wining. As I was facing a project with al lot of unclear requirements and with many changes, that words had a big impact on me. So I started to improve my technical skills and study more at night after work. At that time there was a lot of hype on XP and it was clear to me XP matched my ideas to build software. Through an ex-colleague of mine I met Francesco Cirillo who gave me a lot of spurs on studying something valuable for my work.

Stefano: What motivated you to become a coach?

Davide: Every Xprogrammer is an XP coach; every single development day you, as a programmer, are facing problems about how to implement some features: "is there a simpler way to do that?" "Is there a better test to implement?" "Ouch, that object doesn't behave in the right way, I have to fix it now." "Can I understand that deploy script?". All these questions rise every minute, what I like as a coach is to help the team to find a way to answer those issues.

Stefano: Can you describe what a typical day of a coach looks like?

Davide: It's like to be an alien on the Earth, you have to see and listen a lot: comments, postures, level of good noise, level of bad noise, flying questions, mechanical typing and… code, of course. I don't have a private office, my work is in the bullpen and I keep attention to that indicators, than I try to help the team to work together. It's not easy because people have consolidated habits and dynamics but, all together, we have to move from a local optima to a better one.

Stefano: What is the single most important factor within an organization to succeed with agile?

Davide: That's a good question. There is a no single answer, but there are four   simplicity, communication, feedback and courage i.e. the Values. If a company or a slice of it is not ready to sustain those values, probably it will be precluded to the benefits that agile methods can produce.

Stefano: Have you found any connection between the platform/language a team uses and its success in agile?

Davide: Yep. If you are a professional and can embrace the values above, you are in the right direction, but there are technologies or languages that can match your expectations better than others, so they can make your work easier.

Let's take the value of feedback: you are considering a new language to study, you don't know anything about it, but there is some buzz on the net, so you give it a chance and start downloading the development environment; then you start with a tutorial, but unfortunately you face some show stoppers: you should configure this or that, you are constrained to compile and/or link whatever, you should validate something or throwing some mandatory exceptions to produce your first piece of new software, clearly that scenario does not work in the direction of a fast feedback.

So, it's not a secret I like a lot simple languages like Smalltalk.

Stefano: What final recommendations can you give to team who might want to try or just starting with agile?

Davide: The team members (in the whole) should be professional and disciplined, they should study a lot, start small and ask themselves the whys of every step in their working efforts. Organizing your work this way is a useful path towards improvement and it's fun too

Photo by Varnent

I recently embarked on a journey to read (or re-read) all the great classic books in the software literature.

The Pragmatic Programmer is one of those books which is usually included in the recommended readings for a software developer, and deservedly so. The book, released in 1999, has been so successful that the two authors, Andrew Hunt and David Thomas, have since created their own publishing company, the Pragmatic Bookshelf (with titles spanning a broad range of programming topics).

This book must really have been a breakthrough when it hit the bookstores about 10 years ago. 1999 is one year before Kent Beck released his seminal book Extreme Programming Explained: Embrace Change which exposed the agile software process to the masses. Both Andrew Hunt and David Thomas originally signed the Agile Manifesto, together with Kent Beck himself and a few others, and it shows. But it would be dismissive to describe this as a book on agile since it’s much more.

The book is structured as a series short 46 sections. Each section has challenges and even exercises where appropriate. It touches on design concepts such as orthogonality, decoupling, DRY (which it coined), Domain Specific Languages, Design By Contract, Metaprogramming, Refactoring; it has pages on process topics like build automation, “design to test”, test automation, estimation, requirements collection.

But where the book really shines is where it shows you how to “become a better programmer” (today we might say a software craftsman) and to take pride from it.

The pragmatic programmer is an early adopter, is inquisitive and realistic, and tries to be “familiar with a broad range of technologies and environments“.

The pragmatic programmer takes responsibility, values quality but recognizes when the software is “good enough”. The pragmatic programmer is a continuous learner (the “learn at least one new language every year” advice is often quoted), thinks critically about what he reads and hear, and knows how to communicate. The books explains how you can build these qualities.

The sections that I enjoyed the most is when the authors discuss about tools: the pragmatic programmer prefers working with plain text (the book itself it’s been written from XML transformed into TeX), masters a shell (command line) which he/she can program, knows at least one text manipulation language (e.g. Perl) and how to generate code from metadata.

Even though the recent reprints have links to later tools like JUnit, Ant, etc… still a few parts of the book begin to show its age. For example the authors suggest to pick one text editor (e.g. Emacs or VI) and become a power user (not just know the keyboard shortcuts but also how to extend it to suit your needs). There used to be a time when you could spend your whole working day inside Emacs: you could edit and build your programs, open a shell, handle emails and browse newsgroups, edit text documents (with LaTeX for example), even play games. As much as I love Emacs, I believe today it’s virtually impossible to beat the productivity gains you can get with specialized IDEs like Visual Studio or Eclipse, with their intellisense and plug-in ecosystems.

All in all, the Pragmatic Programmer is easily one of the best book on software development I have ever read. It has really inspired me to continue my journey to become a “better programmer”. Thanks to this book, I have now in my action list: learn a scripting language (Ruby?); learn a functional language (F#?); learn how to use a shell in the Windows environment (PowerShell?); read a book on usability; read a book on the human side of software development (“Peopleware”?). A lot of things. A lot of fun ahead.