Not in code

“I was born for passion, passion in my work and the people relating to it.”

Thanks to James Pott for showing me this wonderful piece on passion by Ron Jeffries.

Much of the agile software movement is about loosening controls, shifting more to asking forgiveness rather than permission. Yet loosening controls isn’t the same as anarchy and no control - a misrepresentation that’s commonly thrown at agilists too. It’s about asking how we can use a minimum of controls, so that that we don’t suffocate the good in our desire to protect ourselves from the bad.

From Martin Fowler’s Bliki: http://martinfowler.com/bliki/WikipediaDeath.html

This eloquent reminder of why I love agile methods hit me hard enough to prompt a post rather than a plain old del.icio.us entry.

This is from an amusing page on the c2 wiki.

The seven habits of effective pair-destroyers:

• Interrupt every time your partner starts doing something in a way other than how you’d do it.
• Insist on doing everything optimally the first time (even optimal keystrokes in the editor). Refactoring is not an option. Nothing fouls the current task better than PrematureOptimization and PrematureGeneralization.
• Don’t allow any idea you didn’t think of to be tried, no matter how small. Insist on being given a complete and conclusive argument that the idea will work and meets every standard of good code as practiced by the GreatOnes? before you yield even one keystroke. Refer to authoritative books to win such arguments.
• Cheat on ExtremeProgramming. Refuse to test first, do one task at a time, do what the customer asked, or any of the other practices that make pairing work. When reminded of the practices, argue and/or accuse.
• Once you wrestle the keyboard away, delete your partner’s last edit immediately. Then do what you were thinking of instead.
• Pair on stuff that is ambiguous so that you can diverge in intent and context every step of the way. (AmbiguityRequiresSpikes.)
• Never miss an opportunity to lecture your partner about good [OO-design|database-normalization|refactorings|math|linguistic-legalism]. Keep arguing and lecturing even after your partner agrees with you. Establish dominance.

David Anderson blogged this humorous piece on why programmers shouldn’t have project management responsibility.

Glen Stampoultzis worked at IBS until a few weeks ago, his last two weeks overlapped with my first two weeks here. He blogged recently about his experiences working in the Agile/XP environment here.

A recent episode of The Secret Life of Us introduced me to the concept of Tribalism and how it affects us socially. David Anderson recently blogged about the same topic but in the context of software development & the agile community. Interesting reading.

• Tribalism Revisited
• 5 Tribal Dimensions

It�s been a month since my last post & 3 weeks since I started at IBS, probably time I posted something about how it�s been so far. So firstly � I�m lovin� it! We�re into our second iteration since I started and the last MXPEG meeting was hosted at our office. Steve Hayes ran an interesting exercise on how distance in communication affects outcomes.

I think it�s always tough being the newest member of a team but this hasn�t really been an issue for me at IBS. I think their(our?) culture of learning(we have a study group each Friday) and the fact that this is an XP team really helps.

One particular XP practice has helped me a lot initially � pair programming.

I was pairing on my second day, and it was great! Pair programming really seems like a great, unintimidating way to get new developers adding value early. It�s probably a bit more like mentoring initially, though I think a good analogy is a new navigator in a rally car. He or she is still a navigator, even if the drivers more familiar with the circuit (and vice versa if they were a new driver). My point being that even as the newer member of the pair you�re still adding some value. Though the more experienced member of the pair carries more of the load initially, compare this is to the alternative � a the catch-22 situation with the existing team member too busy doing �actual work� to teach the new team member to do these same things and therefore alleviate this load. And since logically you would hire new people when your existing team is under the pump, this probably quite a common situation in non-XP teams that are growing rapidly.

I think that pair programming is a huge advantage that XP teams have over teams that follow more a traditional methodology or maybe none at all! With a more traditional methodology you might expect a new team member to add value only after going through several hundred(thousand?) pages of documentation and spending weeks simply learning about the system they will be working with, without adding any direct value.

In my own experience (as a new team member and watching other new members join past teams) the first few weeks and sometimes even months can be a very frustrating experience. You�re not familiar with the code you�re working with, you�re constantly interrupting the people who are while they�re trying to get their work done. All this leaves you feeling like you�re more of a burden than a help which can be quite demoralising and I feel an inefficient way to go about things.

Some teams/companies choose to wear this, perhaps seeing it as a necessary evil. I disagree. There is something that can be done and this has been demonstrated by my own experiences with pair programming in XP.

My lecturer in Software Quality, Graeme Carbines repeated this several times during the past year. I couldn’t agree with him more. When you learn something new, it’s fresh in your mind. If you apply it once you’ve learnt it you refine your understanding even further. If however, several months pass before you have an opportunity to apply it, chances are you won’t remember many of the details - making this knowledge less useful.

Seems to me that when you learn something, is as important as what you learn. - something I should try to take into account as I select my subjects for the upcoming academic year.

I blogged recently that I am starting a new job in a team that strictly practices Agile techniques (XP). It’s seems like this will be the perfect opportunity to apply what I’ve just learnt at Uni (in the Agile Project). It might be a little harder to apply the Software Quality stuff that I’ve learnt, atleast not all of it and not as directly. I might attempt to stay in touch with this by doing more research in the area, perhaps contrasting Agile techniques with more formal & heavy weight models such as CMMI that I studied about. Hmmm, I wonder…

Ok, so most of you probably don’t even know what Evolution Analyser is at this stage…

It’s a product that I’ve been working on for the last few months as part of a university project to learn how to apply agile development methods effectively. Evolution Analyser itself is a Java based application that analyses Java source code and produces a number of unique metrics and reports that when interpreted correctly can tell you a number of things about the “evolution” of the architecture of a Java application over a number of versions. The product itself is the brainchild of Rajesh Vasa, the lecturer for this university subject. It is an area that he has been researching for a number of years and is something that he is very passionate about.

It’s uses? There are so many really, but here are some:
* Analysing open source projects for architectural stability to minimise risk
* To provide a quick “health indicator” of a software project, great for managers
* A feedback mechanism that can quickly communicate when a large architectural change has occurred, again great for higher level managers
* Quickly analysing the software evolution of a company your firm’s planning to buy out/invest heavily in
* And much more depending on how far you can stretch your imagination…

We’re currently deliberating about the future of this project after the subject completes (which is pretty soon). In the meantime do have a browse around our project Wiki. Please excuse the mess, we currently use the Wiki more as a communication medium for the team than as a product website. If you do decide to look at the Wiki then the project diaries section in particular may provide a view into the struggles that our team faced trying to cope with learning so much while still trying to produce a useful piece of quality software. There a link on this blog’s sidebar, for your convenience, here’s another one http://evolution.hiremaga.com/