Recounting the Rationals

Recently I found the paper Recounting the Rationals via Mark Jason Dominus on Planet Haskell.

Mark suggests that the paper is a good first paper to read. Well since I am part way through my first Discrete Maths subject, I thought I would give it a go as my first mathematical paper to have a look at.

I was quite suprised that I could actually understand a fair bit of the paper as I read through it. It was interesting just how many of the concepts from my one Uni subject are brought together in this paper: rational numbers, sequences, trees, proof by contradiction, proof by induction and the notion of relatively prime.

I still need to spend some more time to finish exploring this paper and Brent Yorgey's six-part blog series about it. However a couple observations so far:

• The sequence of rationals shown in the paper is quite elegant and fascinating.


• The fact that the sequence can be represented as a tree is even more interesting.


• Starting with sequences, switching to a tree perspective, doing a number of proofs on the tree and then relating the tree back to the sequences was a pretty cool technique.

So my verdict from the experience, is that it has been a good first paper to read. It is only 3 pages long. I could understand the paper at a high-level to start with and it has been interesting and challenging to explore in detail.

QOTD

Mutable stateful objects are the new spaghetti code

From the Clojure Rationale.

Pair Programming

In the absence of a generally accepted definition of pair programing, for the purposes of this post I define it as two programers sitting at the same computer engaged in working on the program at hand.

I see pair programming as one form of collaboration. Other common forms of collaboration on a a software project include:

• two people standing around a whiteboard discussing the same topic


• in the case where people are sitting at their own desks, asking someone nearby a question about their current work

On a side note, Dave Thomas has talked about having a customer (the person with 'requirements') paired with a developer. This sounds like an interesting idea to explore for some situations. Although I don't think using current, mainstream enterprise technologies (eg. Java, C# based) would be suitable here, due to the time it commonly takes a developer to do something that would be meaningful to the customer.

My expectation of software developers on the teams I am involved with, is that for whatever task they are working on, they will choose to collaborate with their other team members in whichever ways bring the best business value. Some factors that I have considered in such a decision include:

• complexity/familiarity with the task


• skills and abilities of the team members


• knowledge sharing - in a tangible sense this translates to things such as skills transfer between team members and setting up the project to function appropriately in the case of a team member being unavailable

By the previous statements I disagree with extreme programming and the derivatives that mandate pair programming for all committed code (or are increasingly working towards that objective). Of the numerous projects and people I have been involved with over the last five years, I have not seen the case where such a rule would deliver the best value to the customer, or close to it.

To clarify, I am not blatantly for or against pair programming. It has situational benefits and costs, just like the other forms of collaboration.

Finally, there is one factor that is rarely mentioned by others in my discussions on this topic. That is pair programming sets up a more social work environment, which some people really enjoy more than others. This blog post is already long enough, so I won't comment further on this, except that I would like to see people be honest with themselves if this is a motivator for them. Especially if they are trying to convince others about pair programming.

Online Discrete Maths Resources

MIT has some readings for their Mathematics for Computer Science course.

Carnegie Mellon University also also posted lecture notes on a wiki.

What is an agile project?

It seems that I have a different view of what an agile project is, compared to most of the people I talk to about it. Maybe it is because I am involved in business as well being a software developer.

I assume a software project exists as part of meeting some objective. Often it is a business objective, but could also be non-commercial, such as academic. I will call the party (business or academia) that has the objective and that is paying for the project, the customer.

Looking up the dictionary on the Mac I am writing this with, the definition of agile is:

able to move quickly and easily

Applying that to a software project, I see it as a project where the customer has been able to quickly and easily move in their attempt to achieve their objective.[1]

The interesting twist on all of this, is that at the beginning of a project, the customer usually doesn't know precisely what they want to have at the end of the project. I can think of a few reasons for this:

1. When design/programming starts, some of the requirements are ambiguous and/or logically inconsistent


2. There are known problems yet to be solved


3. For some reason, after work starts, but before it is finished, the customer decides that the set of requirements is different

The standard 'Agile' way of dealing with these issues is to accept them and then have the customer heavily involved throughout the project, clarifying ambiguities, making cost/benefit decisions when presented with alternative solutions, planning and re-planning. (i.e. scope and cost are more transparent and can be pro-actively managed in a holistic manner by the appropriate party)

Now, a project may use an existing Agile Methodology to define the process they will follow. Developers may use particular 'Agile' development techniques that they think will support the project. However, if both of these occur on a project with the above issues, but the active customer involvement is missing, then by the previous definitions the project is not agile.

Unfortunately some of the 'Agile' projects I have been involved with and most of the 'Agile' projects I talk with people about are in this category.

[1] Quickly and easily is relative to the actual complexity of their objective