Martin Fowler

The new methodology

In the past few years there’s been a rapidly growing interest in “lightweight” methodologies. Alternatively characterized as an antidote to bureaucracy or a license to hack they’ve stirred up interest all over the software landscape. In this essay I explore the reasons for lightweight methods, focusing not so much on their weight but on their adaptive nature and their people-first orientation. I also give a summary and references to the processes in this school and consider the factors that should influence your choice of whether to go down this newly trodden path.

Reducing coupling

0 7 4 0 7 4 5 9 / 0 1 /

Public versus published interfaces

1 0 . 0 0

Question time! about use cases

One of the growing trends in software design is separating interface from implementation. The principle is about separating modules into public and private parts so that you can change the private part without coordinating with other modules. However, there is a further distinction-the one between public and published interfaces. This distinction is important because it affects how you work with the interface.

Module assembly [programming]

In Britain there is a very successful form of panel session, on a television program called “Question Time.” In this programme, four panelists, all public figures, are chosen to give a spectrum of viewpoints. There is always a figure from the two main political p<a.rties, usually one from the third largest party, and some complementary figure, perhaps a a business leader, union leader, or media person. This gives a wide spread of views. There are no position statements, the program is filled by discussing questions at about 10 minutes each. Each question is asked by an audience member, all four panelists respond, moderated by the panel moderator (a well known BBC ligure). The questioner then makes a brief reply, and there is a brief period of comments from the floor. The questions are submitted in advance by the audience members and the progr‘am organizers pick six questions that will be interesting. This panel on use cases follows roughly the same format. A well known (English!) 00 figure will question four expert panelists with differing views, to expose their views and their reasons for differing. There are no position statements, the 90-minute pane1 is filled by discussing eight questions. The questions are submitted in advance by the public and audience members. The moderator picks eight questions that will be interesting and help tease ap‘art subtle issues and differences between the panelists. For each question, all four panelists respond, moderated by the pane1 moderator. The questioner makes a brief reply, and there is a brief period of comments from the floor.

Using metadata

How to modularize a program is one of the most general and important issues in software design. Approaches such as object orientation, aspect orientation, components, and services are all different twists to modularization. Whatever route you take, separating the interface from the implementation and separating configuration from use are two vital principles in a good modularization scheme.

A Pedagogical Framework for Domain-Specific Languages

I occasionally come across people who describe their programming tasks as tedious, which is often the sign of a design problem. One common source of tedium is pulling data from an external source. You almost always do the same thing with the data, but because the data differs each time, its difficult to reduce such tedious programming. This Is when you should consider using metadata. To illustrate the approach, consider a simple design problem: build a module that will read data out of a simple file format into memory. One example of this file is a tab-delimited format with the first line containing the names of the fields.

Yet another optimisation article

A framework for thinking about domain-specific languages (DSLs) divides them into internal DSLs, external DSLs, and language workbenches. In all cases, its important to have an explicit semantic model so that they form a veneer over an underlying library. DSLs are valuable for increasing programmer productivity and improving communication with domain experts.

Separating user interface code

The author addresses the question: how do we achieve a fast program? For many programmers, performance is something you pay continuous attention to as you program. Every time you write a fragment of code, you consider the performance implications and code the program to maximize performance. Some performance work comes from architectural decisions, some from more tactical optimization activity. The author considers a specific set of steps for program optimization.

The software engineering of internet software

The first program I wrote on a salary was scientific calculation software in Fortran. As I was writing, I noticed that the code running the primitive menu system differed in style from the code carrying out the calculations. So I separated the routines for these tasks, which paid off when I was asked to create higher-level tasks that did several of the individual menu steps. I could just write a routine that called the calculation routines directly without involving the menus. Thus, I learned for myself a design principle thats served me well in software development: Keep your user interface code separate from everything else. Its a simple rule, embodied into more than one application framework, but its often not followed, which causes quite a bit of trouble.