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

Speed vs Quality

It seems that there were some issues with voting machines in the US recently. Paul Johnson proposed a reason why.

Too often projects are run predominantly with a short-term business focus. Lip service is paid to quality, but when things get tight, it is not actually that important. However, all that changes once the project is 'finished'. Suddenly the longer-term becomes more important, but by then it is too late.

In a software project, there is generally a relationship between quality ¹ (from the developer perspective) and speed of development (from the business perspective). You can sacrifice quality for speed, but as the project becomes bigger or more complex, it becomes harder to change and so development speed decreases. The short-term gain (probably measured in days/weeks) becomes a long-term loss.

At the other end of the spectrum, you can spend most of your time focussed on quality and not worry about speed of development. As previously posted, this is not commercially sustainable either.

IMHO, one of the most interesting things Agile Methodologies bring to a project, is the opportunity to make development cost/speed and quality more transparent throughout the life of the project. In the end though, someone has to make decisions about quality and speed on a day-to-day basis. It seems to me that a business savvy developer will be more likely to succeed than a tech savvy business person. It is a tough line to walk though.

¹ Quality means different things to different people. In this case I am referring to both how well code is written and whether it exhibits correct behaviour.

Lockharts Lament

Lockharts Lament is a very interesting and worthwhile read. It is about mathematics, art, society and education. Especially education. A few interesting quotes and ones that made me laugh:

"The only people who understand what is going on are the ones most often blamed and least often heard: the students. They say, “math class is stupid and boring,” and they are right."

"High School Geometry: Instrument of the Devil"

"We’re killing people’s interest in circles for god’s sake!"

"The first thing to understand is that mathematics is an art."

It is a about 25 pages long, at least read the conclusion (the last two pages).

Via Enfranchised Mind.

Tim Sweeney - FP, Type Systems in game development

Tim Sweeney of Epic Games spoke at POPL 2006 about development of the successful Unreal 3 game engine. In his slides, he looks at challenges as well as potential solutions such as functional programming, stronger, static type systems and STM. It seems he has now started research on Unreal 4. It will be interesting to see what comes out of his work.

There is also some comments from Tim and his staff on his slides at Lambda The Ultimate.