Agile tells us to the do the simplest thing that could possibly work for the things that we need right now. Why do we do the simplest thing? The answer: Because it is cost effective, especially because the future is unsure. For example, when the business does have something similar, are we sure they’re not going to want it to do something more that will need more work done? Or perhaps the cost of making something “general” could be better spent on more immediate priorities, because if it never gets used, the cost of building (not to mention maintaining) the general infrastructure is wasted.

So what if your business tells you that they want something for now, but make it general, so if they want to do something like it (but not exactly like it) they can reuse the infrastructure to do it again? Even if the business or the analyst is driving this requirement, it reeks of having a bad smell, and is probably driven by a Fear of Waiting. To me this could mean one of several things:

1. Release Cycles are not often enough – Waterfall projects typical schedule a release for anything between 3 months up to a year or more. If requirements do not get in, it is a very long time until they are revisited. Agile addresses this with the Release Often principle that emphasises more requirements prioritisation over requirements identification and freezing.
2. Too many competing priorities – With smaller release cycles providing more restrictive timelines, the next issue is working out what can be fit into that release cycle. Businesses typically have many competing priorities, with waterfall models trying to fit all of those priorities in (leading to bigger release cycles). Agile attempts to get people to prioritise what is most important to them right now.
3. Not Enough Bandwidth – The amount of business value that can be delivered is a function of the fixed time that can be available and the amount of work that can be produced by available resources. I am specific amount the amount of work produced instead of simple the number of people because it is not simply about the number of developers available (read the Mythical Man Month if you want to learn more). Typical waterfall methods rely on judgement (estimates that become promises) to give a guide as to how much can be provided. Agile provides better metrics in the form of a historical moving average of points (e.g. storycard points) per iteration that indicate a better guide as to what can be delivered.

So what can we do to alleviate this fear? Agile has many values and two key ones that spring to mind is around visibility and communication. Visibility is about making people aware of issues (in this case, a fear) and to try to work out what the real motivation is (especially if it is not a real business need). Communication is about making the process transparent and how it is (or can be helping if it is not) to alleviate those concerns.

Our last iteration introduced full time pair programming as an accepted practice (in contrast with our previous practice of “pairing”). The last couple of days I’ve been pair programming with one of client’s developers and because we seem to work well together, it hasn’t been hard to all building the synergy. As part of pair programming, I suggested we give pair pong programming a go and despite it being a new practice, we’ve found it excels at providing us with the rhythm that makes us amazingly productive.

I think there are a couple of reasons why pair pong programming works. Firstly, it’s got all the aspects of pair programming (such as constantly discussing design, questioning and trying to improve on the code that is written). As I mentioned earlier, it’s got the rhythm of proper TDD (writing a failing test, and then getting that test to pass) and finally it’s really good for actually forcing pairs to drive and navigate for an evenly distributed time. I think we’ve almost got to the point where when we write the test for each other, the other pair already understands what it would take to implement it and then the code just flows.

With the right partner, pair pong programming can be such bliss…

The last two weeks have been rather chaotic with the introduction of a whole set of new environments (one for User Acceptance testing, one for Performance testing, and one for our new Oracle database). We’ve had a number of issues moving to each of these environments, highlighted by both our own set of test suites and by our testing team.

Although all the new environments were supposed to be replicas of production, there were still many not-so-subtle and definitely unintentional and unnecessary differences (such as basic Oracle configuration of the NLS_DATE_FORMAT and NLS_TIMESTAMP_FORMAT values). Working with my, it-doesn’t-work-until-it’s-proven (with a test) attitude, has now lead to a whole new suite of “Environment Acceptance” tests that we can now run against each of these environments to further narrow our scope of debugging to just our code.

It is of great relief to have feedback should these things go awry again, but I’m now concerned that a whole other part of IT (operations management including people like systems and database administrators) may be lacking the discipline (or is it the awareness and importance?) of continuous integration and testing.

I’ve been a little bit quiet on the blogging front, both personal and work related (or at least it feels that way). The last few weeks have been busy, as I’ve been getting back into my normal routine (riding heaps!) coupled with the preparation of two major presentations. The first of these, intended for an audience internal to my company for this weekend, has had most of my attention for the better part of last month. The second, which had been the focus of this month, was for the Agile India conference that I had been accepted into. This presentation (more like a workshop), titled, “Priming the Pair Programming Practice For Production” (I couldn’t resist the alliteration), was aimed at providing an environment for people to experience pair programming first hand, with the benefits of coaching that would usually be lacking in the workplace.

I had been designing the session to expose people to both the benefits and challenges associated with this practice that is best learned with hands-on experience. Unfortunately for me, due to a whole series of recent events and bad timing, I have had to withdraw from the conference.

Now that I will not have the chance to actually run my workshop, I may as well describe what had been planned. In addition to going over the thinking behind pair programming, all of my exercises had been designed to give as much practice as possible, coupled with constant feedback, to pair programming and other agile practices. The first two exercises were intended to be fairly trivial, a programming problem to be tackled in pairs, the second, a pair programming refactoring session. I was probably most looking forward to the third exercise (especially from the participant’s reactions) which I had named “Pair Pong”, after the game “Ping Pong”, combining pair programming with the agile practice of Test Driven Development (TDD). Much like the real game, a token (in this case, a keyboard) would be constantly passed around between the pairs. One partner would write a test case to represent a requirement out of a given list, while the other would write enough code to get it working. The roles would swap and the game would continue until all the requirements were complete, with the aim of the pairs to only ultimately communicate via the code they passed between each other.

Although the “Pair Pong” concept is not new, I think associating it with something that everyone can relate to can make it easier to actually implement. I’m sure I’ll have an opportunity to run with this workshop one day; I just know it won’t be next week.

The other day, I commented on how I had participated in my first proper pair programming session. Compared to the “pairing” session I had back in November, (where I was, more often than not, the back seat passenger instead of Navigator) this experience beat it hands down. As keen as I have been in the past to attempt pair programming, project constraints have never really been conducive to real pair programming. Luckily I had been preparing for this opportunity unwittingly by reading “Pair Programming Illuminated“. The book that Brett had kindly loaned me was an excellent resource for describing constraints that hinder and identifying techniques to improve pair programming practices. Read more “On Pair Programming”

I’ve been working on a story card that is part of the “critical path” by enhancing a framework not really designed for what we need it to do (not that they ever are). I have almost no test coverage, very little documentation and a completely different architecture and context to work in. I think that after today, I can honestly testify to my first proper pair programming experience. I intend to write more once I identify what made it all flow, but let’s just say I’m hungry for more. Stay tuned.

Pair programming is one of the many Extreme Programming practices that I haven’t been able to use that much on my current project. We have a substitute dubbed ‘pairing’ which attempts to reap the benefits of this practice without incurring its perceived overheads. Part of ‘pairing’ allows us to pair program in certain circumstances (other factors prevent us from doing it actively all the time) and I recently had my first experience (or should that be an epiphany?) to reflect upon.

My first observation during this process was that I found the quality of code I wrote, and even my focus of what I was writing, increased tremendously. I also found myself absorbing more history and appreciation for the code I was adding to, instead of simply getting my tests to pass.

After enjoying my first taste of pair programming, I can conclude that to be really effective at it will definitely take a lot of practice. For example, one of my pair partners commented that I tended to unconsciously ‘huff’ while he was typing (probably because I can type much faster than him or was it because I found myself the victim of the Dominant Pair Syndrome?). Appreciating the feedback (of which I find myself so undersubscribed these days) I started to scour the net trying to look for some resources that described better pair programming etiquette. C2 Wiki has a good collection of resources such as ‘How To Piss Off Your Pair’, Pair Programming Questions, and Pair Programming Doubts. I’ve now added Pair Programming Illuminated to my wish list and am eagerly waiting for a copy of Peer Reviews In Software: A Practical Guide in my next Amazon shipment.