Eastgate describes Tinderbox as a personal content assistant that helps you visualize, analyze, and share your notes, plans and ideas. It's an interesting application to use. One of the key benefits I've obtained from using Tinderbox is the exploration and use of frameworks.

The benefit of using Tinderbox to explore and use a framework is twofold. First, you gain insight into the framework by developing a Tinderbox document describing it. Second, use the Tinderbox document describing the framework to explore a problem using the framework. It is this second benefit where Tinderbox really shines.

Exploring a framework often requires mapping out the components, understanding the purpose of each component and the relationships between them. Tinderbox serves all three requirements very well—by writing notes that describe these components you fully capture the framework. By using links to capture relationships between components and using borders and badges for notes you can create a visually appealing document that describes the framework.

A good example of using Tinderbox in this way is the document developed to explore framework provided by Edward de Bono's "Teach Yourself to Think". The entire Tinderbox document developed to describe Edward's framework is shown in Figure 1.


In this framework, Edward introduces five stages of thinking and ties them together in a way that helps formulate new insights into problems. Figure 2 provides a closer look at one of these stages.


The most important part of Figure 2 is the note within the PO stage (called "PO Test"). This note was collected by an agent defined in the Tinderbox document. Agents are a powerful way to collect and organize information in a document. By using an agent to collect notes for each stage in the framework you can get a good picture of all of the information available in this stage. The arrows pointing into the stage highlight the key points needed for developing ideas in this stage.

These arrows are just Tinderbox notes. The advantage of these notes is that in addition to the title you can add additional information in them to remind yourself of what it means to say, "Search for Routine Approach".

The advantage of combining Tinderbox with a framework is that the end result is a living document that can self organize itself. Since Tinderbox supports multiple views of the data you have it provides the additional advantage of reviewing the information in the document through different perspectives. Since a Tinderbox is written in XML there is the additional advantage that you can share the document with other people (who may not have Tinderbox).

Of course, you can't apply Edward's framework to every problem you encounter. Applying the framework in a Tinderbox document is helpful for solving hard problems where no easy solution is readily apparent. I use it for the big problems that need to be thought through and analyzed.

I've been using iOS 5 for a week now. It's installed on a iPhone 3GS. The upgrade was a little painful because of the time it took but relatively easy overall.

To obtain iOS 5 you need iTunes 10.5. This is a large download around 500MB in size. There was also a Lion upgrade available. You need to Lion upgrade if you want to tie both your phone and your computer to iCloud but you don't need the Lion upgrade to use iTunes 10.5 (see the iTunes System Requirements).


Downloading both iTunes and Lion doubles the download size to almost 1000MB. The iOS 5 release itself is another 668MB. Expect this to take a while on a slow Internet link. If you are on a slow Internet link you should be aware that iTunes doesn't support pausing the download.

Within iTunes, you can pause the iPhone upgrade during the backup of the phone but not during the download of iOS 5 itself. Pausing the download in iTunes results in a complete loss of all of the downloaded data. You are forced to restart the download at the beginning. If you expect to have to pause the downloads you are better off downloading the iOS 5 image manually through Safari.

Installing iOS 5 takes longer than other iOS upgrades because of the firmware upgrade. The firmware upgrade basically means that you have to back up the phone, install iOS 5 and then reinstall everything on the phone. The process is automatic but don't expect it to occur quickly.

The most impressive part of the upgrade is iCloud and the Find My Phone support that comes with iCloud. Most of the other features in iOS 5 are not that significant for a iPhone 3GS user. Notifications are better but not reason enough in and of itself to justify the upgrade. For some reason the music and video libraries are split so look for your videos in the video application.

I was disappointed to find that reminders don't include location based information. It's not clear to me that this is a technical restriction—the phone already supports many other location based services. The argument that this feature was disabled on the iPhone 3GS to force users to upgrade doesn't hold water with me as the presence or absence of this feature wouldn't justify the purchase of a iPhone 4G.

The upgrade makes the phone run slower. I notice significant delays when listening to music and trying to unlock the phone, among other activities. Once past the initial delay the performance of the phone is pretty good. The annoying delays only seem to come into play when changing applications.

Overall I like the upgrade. The performance hit I attribute to the software upgrade isn't altogether unexpected but it is a little inconvenient. The notifications are nice and I enjoyed the iCloud integration, especially the Find My iPhone and Photo Streaming. Overall however nothing in the software upgrade justifies the purchase of a iPhone 4G. Too bad because I was looking for a reason to upgrade the hardware. Guess I'l be waiting for the iPhone 5.

I am re-reading Mike Cohn's book "Agile Estimating and Planning". Chapter four, "Estimating Size with Story Points", introduces the concept of story points and velocity.

Story points represent a relative estimate of the complexity, size or risk in a story. As a relative measure the focus is on assigning stories of similar complexity, size or risk the same number of story points. A relative measure simplifies estimation because it separates size from duration.

Velocity is a measure of the number of story points a team completes in an iteration. Use common sense when managing velocity. For example, if someone takes a day off during the week their contribution to the team's velocty should be reduced.

Story points provide the abilty to correct estimates as velocity changes without having to re-estimate the stories themselves. For example, a team with a velocity of 25 might find itself moving closer to 20. This change increases the duration of the project because the total number of story points is known but the rate at which they are completed is reduced.

Duration calculations using velocity need to be considered in light of the assumptions velocity brings with it. For example, such calculations assume that all things remain equal over the course of the project. This means that personal changes on a team will impact velocity. It also means that duration calculations should bear in mind the lessons of the cone of uncertainty.

... suggest there are two complementary approaches for achieving change. The first has to do with producing economic value. They argue that people will adopt an approach that produces higher value. They couple this with a high involvement high learning organizational approach. High involvement will bring about the change.

2018-06-06:

The link to Achieving Change in Construction is offline. The URL above is a capture by the Internet Archive from when this article was published.

I am re-reading Mike Cohn's book "Agile Estimating and Planning". In chapter three, "An Agile Approach", Mike references the Manifesto for Agile Software Development. A lot has been written about the manifesto. I won't add much.

Two things stand out that are very enlightened. First, the acknowledgement that we are still learning how to develop software better. Second, the emphasis on people rather than tools and process.

The first point reflects an enlightened view of software development, particularly if you view software development as knowledge acquisition. You are learning how to do something that perhaps no else is doing. That is a hard job and worth acknowledging.

The second point reflects an enlightened view of software development because it recognizes that people are the important element in the creation and use of software. The shift in focus is a stroke of genius. It reflects a change in understanding around who is developing and using the software.