Field Study Of The Software Design Process For Large Systems

: "A Field Study of the Software Design Process for Large Systems"
: by Bill Curtis, Herb Krasner, and Neil Iscoe,
: Communications of the ACM, (V 31, N 11) November 1988, pages 1268-1287.

The paper studies big, mostly military, systems. They usually took hundreds of people for half a decade or more.

This paper says lots of interesting things. For example, it makes an argument for use cases. "Designers needed operational scenarios of system use to understand the application's behavior and its environment. Unfortunately, these scenarios were too seldom passed from the customer to the developer." (p. 1282)

Here are some more quotes.

"Many projects have one or two people, usually senior system engineers, who assumed prime responsibility for designing the system. On about one-third of the projects we studied, one of these individuals had remarkable control over project direction and outcome, and in some case was described as the person who 'saved' the system. Since their superior application domain knowledge contrasted with that of their development colleagues, truly exceptional designers stood out in this study, as they have elsewhere, as a scarce project resource."

"Our interviews revealed that the thin spread of application knowledge among the project staff was a significant problem on many software development projects."

"Someone had to spend a hundred million dollars to get that knowledge in my head. It didn't come free".

I think that half of the problems of software development would be solved if everyone involved with it understood this paper. This paper doesn't propose any solutions, but if people understood the problems then they would quit some of their stupid behavior. For example, the paper makes it clear that application domain knowledge is the most critical resource on most projects. This would convince managers that it is critical to keep senior designers around. It would convince them that new hires can never replace senior people. It might also convince them that they can't depend on methodologies or new programming techniques to solve their problems if they are not first ensuring that their people have the proper domain knowledge.

"Writing code isn't the problem, understanding the problem is the problem."

-- RalphJohnson

Supposedly there's a copy at http://portal.acm.org/citation.cfm?id=50089&dl=ACM&coll=portal but you need a login to get it. Furthermore, after four hours I've still failed to get a response from their automated website to activate my account. See AcmPortal.

Part of the problem is that users often cannot pass on the above-mentioned scenarios - they don't know them, or they don't want to share them (when there are informal work-arounds next to official formal procedures for example...) Or worse they don't understand the problem themselves. Some of the projects we get are more a mess than a problem. Sometimes we -- customer and developer -- only start to understand the problem when we start building a solution and get feedback. We not only need good domain knowledge, we sometimes need good facilitators too. There are many cases when there is not just one "truth" in the organization. We talk about the user -- but who is the user? The manager, the people working with the customer?

-- MartineDevos

I was terribly confused at OOPSLA97 by the topic of the panel you and Kent were on: "Do Frameworks Reduce Discovery Costs?" I wanted to ask why people weren't asking "Does Domain Analysis reduce discovery costs?" Learning from the code is great, but I (at the time) thought why can't people model the hell out of a domain and keep the models up to date (MercenaryAnalyst) and treat them as company assets? Better yet, teach the domain experts how to model to convey their understanding. MartinFowler mentions modelers without software backgrounds in AnalysisPatterns. Seems like direct communication would be better than learning about a domain from a framework.

-- MichaelFeathers

Even better, just make domain experts available to talk with the developers. No model, no matter how good, is as useful as someone who'll talk with you about what's really up. The reason is that a model is just a program in yet another programming language, and an untestable language at that. A model written by a domain expert is an untestable program written by a non-programmer. Can you spell DOOM? I mean this in the nicest possible way, of course. -- RonJeffries

General, can you spend some time with our developers? Answer: No.

Try "General, can you spend some time to make sure we really understand battlespace management problem?"