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.