Weeks three and four, where have you gone? A few games of tennis, Advance Wars and a little thesis hacking and a fortnight disappears. It has been fun, though.

My write up is starting to look serviceable, if not great. I spent most of the last fortnight working on six example scenarios that demonstrate how my Concern Maps tool can manage crosscutting concerns in programs and documents. This drove out a few defects that needed fixing, testing etc, which in turn meant building NUnit for beta 2, so I ended up spending a couple of days cutting code. Everything is green now. I aim to have a serviceable draft by the middle of this week, which will give me plenty of time to edit over the next few weeks.

Week two complete, I'm now at 50 pages of thesis. This is just related work and an intro to what I'm doing, so I am going to need at least a week to pare it back. Jogged 60km last week, I think I need to try a new route now.

Thesis aside: I usually use www.dictionary.com to check meanings. It has been down for about 24 hours. In searching for a replacement I stumbled on this list of the Cambridge Dictionary's most popular words of 2004. I'm glad that other people also look up effect # 3 / affect #15 every now and then.

Jogging aside: I listen to ITConversations.com while I am running, good stuff this week includes Werner Vogels on large-scale asynchronous systems and epidemics, Tim O'Reilly reprising his Web 2.0 thing and Andrew Morton on Linux development and the economics of OSS.

And speaking of Web 2.0, Tim mentioned patterns of Web 2.0 applications. I'd like to see someone write those up. "Network effects by default", "Design for participation", "Remixable applications" etc.

The Google Blog says they are looking for chefs, but I think they are just trying to influence readers into working for them on the strength of their menu. My vote: "Seared Day Boat Scallops in Green Coconut Curry Sauce".

This reminded me that I haven't recommended the book Freakonomics yet. It's a lot of fun so read it. I bought it from a Borders in Washington Dulles at 5am and read it in one sitting.

I'm one week into my thesis. Brief summary of the last 7 days in numbers: thesis pages written 25, KM jogged 68, avg. coffee shots / day 4.5. So all-in-all progress is OK but not great. Only when confronted by writing documents do I recognise the unadulterated pleasure that is hacking on code. Hopefully I'll be back on that in a couple of weeks.

Here's a small taste of the thesis so far - a still rough introduction to the place where cross-cutting code, modelling and requirements traceability meet up:

The "divide and conquer" approach to problem solving allows people to build complex software systems. The de-composition of software code into modules is fundamental to software development. Benefits seen by [1] include manageability, flexibility and comprehensibility. The organisation of software development into a process also produces specialised activities, like project planning, requirements gathering, design and development. These in turn make specialised artefacts like test plans, requirements and design documents and source code.

This specialisation produces the following benefits:

• A project or system can be de-composed into smaller items of work
• Items of work can be completed by people with specialised skills
• Items of work can be monitored separately

This decomposition optimises the ability of people to focus on one part of a problem at once. As noted in [1] one modularisation of source code will optimise one part of a system, usually de-optimising another. This tension is played out in the organisation of software into modules, projects into phases, and information into documents.

It is useful to consider this trade off using the idea of a concern – defined as any thing that must be considered separately and is a relatively well defined entity within software [2]. By dividing the software development process into stages (for example requirements, then design, then development, then implementation), the process optimises concerns like "the requirements" and "the design" over slices of related work, like "bank account withdrawal".

Looking at the de-composition of software into modules, it is also interesting to think about the kind of concerns that are optimised. Classes, components and services all optimise a particular concern – the unification of data and related functionality (class), the encapsulation of cohesive functionality (component) and the description and exposure of functionality through a coarse-grained distributed interface (service). This section examines the concerns that are de-optimised by process and software design so that they are not neatly modularised, called cross-cutting concerns.

1 Parnas, D.L., On The Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, 1972. 15(12): p. 1053 - 1058.

2 Kiczales, G., Concern's Definition, aosd-discuss mailing list, Editor. 2003.