Nikon D40x

Lauri and I finally got around to getting ourselves a decent camera (we split it for Christmas). I had been loving my Dad's Canon Rebel XT and was taking pictures with it whenever I could, but we only see my parents roughly once a year.

Costco had a Rebel kit with a couple of lenses that I had my eye on, but we decided to buy it a couple of days before christmas and they were all out of the rebel. Instead we got the Nikon D40x with a AF 18-55 and AF-S 55-200 lenses. I am pretty impressed so far.

Here is a little taster of the types of pictures it can take.

OLPC

I participated in the Give One Get One program for One Laptop Per Child last week. For just over $400, you purchase two XO Laptops, one of which you get and the other is donated to the cause.



Fascinated by the little machines, I also setup an emulation on my own laptop to give the system a try. It is a Sugar based interfaced running on Fedora Linux.

The preferred development language for building apps on the XO is python. The kids get to play with python through one of the apps that comes on the laptop called Snippy. In about an hour I was able to get everything up and running and build and install a simple 'Hello World' app.

We won't actually get the laptop until mid January. I can't wait to see my kids get stuck into it.

Software Risk Swaps

In a previous post, I offered examples of trading unknown costs for known costs such as trading the unknown cost of finding bugs for the known cost of automated testing.

This article expands on that concept further, and compares the choices that we make in our projects to a common financial product called an Interest Rate Swap.

Interest Rate Swaps
An Interest Rate Swap is a contract that two parties enter into, which dictates regular cash payments to be made based on the interest on a notional amount. Most commonly, one party will pay a fixed amount of interest (say 5%) for a floating amount of interest (say LIBOR + 1%). Each month, the difference between the two amounts is exchanged.

LIBOR is a market rate that goes up and down as the markets perceptions of interest rates change.

For example, lets say that party A pays an annual 5% fixed interest on $1M in monthly payments. 5% of $1M for one month is $4166. Counterparty B pays LIBOR + 1% on the same terms. If LIBOR was 3.9%, the monthly payment would be $4083. In this case, the guy paying floating should receive $83. If LIBOR moves to 4.1% then the guy paying floating owes $83.

Some more examples are here and here.

Generally speaking, people (businesses) enter into these contracts because they either have an appetite for interest risk or they want to reduce their risk (or exposure) to interest rate changes. The party that takes on the risk (pays floating) usually gets compensated by receiving a higher fixed amount.

Software Projects
Unfortunately, such financial instruments don't exist for software projects. Building software is a tremendously complicated and organic activity that we can't button down into neat transactions. Consider for a second that we could enter into such agreements for our software projects. Which side of the risk equation would most software buyers be on? Would they want to increase or decrease their risk?

Almost always, software buyers want to reduce their risk.

Choices that we make
Lets take another look at some of the choices that we make in our software projects that can increase or decrease risk.

• Automate tests now vs Find bugs later


• Keep things nice and organized as we go vs clean up later


• Make information available vs hiding it


• Building for now vs building for the future


• Designing as simple as possible vs over complicating things


• Pair Programming vs Single Programming

These techniques are proven to reduce risk for a reasonably fixed cost. As stated above, software buyers are all in the risk reduction business, so why doesn't every project employ these techniques?

This is certainly a topic that is up for debate, but here are a few reasons that I can think of.

Can Do Attitude
In their book 'Waltzing with Bears', Tom Demarco and Timothy Lister talk about a teams tendency to ignore risks for the absurd reason that they it is considered to be 'thinking negatively'. The result is the socially more acceptable positive thinking and a 'Can Do' attitude that doesn't put any emphasis on what could go wrong. For example, why spend time automating tests when you have such a great group of programmers. We don't want to accept that programmers are going to introduce bugs.

Clearly this is naive.

Lack of Skills
Most of these risk reduction techniques are far from trivial to implement. They take commitment and understanding at all levels to implement and they are still gaining popularity in the industry so not all teams have the skills required.

Buyer Commitment
A case also needs to be made to the manager/buyer. On the surface, Pair Programming seems ludicrous to a manager, like 2 guys digging a hole with one shovel. Instead of paying $75 a hour to develop software, it now costs $150 an hour. How could that possibly make any sense?

You have to look at the whole picture, isolate variables and look at cause and effect to see the impact. How Pair Programming reduces risk is a bigger topic that I will be looking at in a future posting.

Conclusion
There are a number of software development techniques listed here that can reduce risk in a project. They can be thought of as trading a fixed cost for a floating cost. They take commitment and understanding to implement, but they offer stability and that is often what is desired the most by software buyers.