Notes on Martin Fowler's Lecture

by Tim David

Martin Fowler spoke last night at OTUG (Object Technology User Group). He gave a very informal presentation, not using slides or a prepared speech. Fowler was much more subdued and thoughtful than the last time I had heard him speak 4 years ago, but he was still very opinionated and had interesting things to say.

Here are some of things I jotted down:

Don't try to separate the design of software from its construction. Don't do extended amounts of design without proving the design by programming. However, you also should avoid programming without doing any design. You need to consistently rework the design and keep it clean to "not allow cruft to build up". Clean design is very important. On a development team, it is important that several people have "the will to design". These are the people who are constantly examining the code, and finding and fixing problem areas.It is very important to go back and clean up code. Keeping code clean and well factored is what allows the code to be more easily modified in future for new business requirements. Don't try to anticipate future requirements. Trust more in your ability to adapt the code to future requirements than to your ability to predict what the future requirements will be.

Since design should not be separated from construction, it is hard for a manager to tell if design has really occurred. Only a technical member of a team can really tell if design is happening appropriately. This can be scary to a manager. They have to trust the team (or at least part of the team) to tell them if the design is good or bad, or if enough design is being done. It is much easier for a manager to just mandate that there be a "design" phase with some specified deliverable, rather than to trust their developers to do design as needed.

Dennis Ritchie of Unix fame supposedly took out more code than he wrote, in an effort to keep the design of the Unix code clean.

The people on a development team are more important to its success than any particular development methodology or technique. It is their skills and how well they work together that ultimately determines the success of a project.

It is important for the software development community to examine itself closely to see what various techniques have been used to create good designs and to successfully develop software. It is important to understand that not all techniques will work for developing all kinds of software or for all development teams. Teams developing real-time systems, or developing specialized software like compilers, probably will have different techniques than those developing enterprise / business applications. This is to be expected. One size does not fit all. It is important to try out different techniques and find what works in your particular environment.

It is good to look at the "schools of development" that have evolved to see how they worked. Specifically, the schools of development around Unix programming, LISP programming, and XP. Some things these schools shared is an emphasis on short cycles, with quickly proving designs with code. In all three, the code evolves without a master plan. Good design has cohesion. It is understood across the entire team, developers, analysts, and business people. It creates a system of names; names that fit together. This is the "ubiquitous language" described by Eric Evans. He emphasizes the language will evolve over time. It is not wholely the language of the business owner, because the developer needs a more rigorous and precise defination than the loose terminology a business person may use. This is a language developed jointed to facilitate collaboration between the parties.

He had high praise for Eric Evan's book "Domain-driven design". Eric is coming to Minnesota to give a presentation sponsored by OTUG in April.

It is reasonable to do "specification by example". It is usually much easier to have business owners give you examples of how they want the software to perform than to have them write rigorous, formal requirements.

Erich Gamma once said of Fowler, "he's a pretty good programmer for an analyst".