an entry from

Piotr's R&D blog

This is a long and rambling entry -- panels are very difficult to summarize, especially live, on the spot. Feel free to ignore this item, there's nothing groundbreaking in here.

There's 3 panelists, and they gave 3 very different position statements; different not in that they have different opinions on the topic, but in that they weren't even talking about the same thing! They all seem to argue, though, that we need science in design, whatever it may be, and that we should reach out to other disciplines for help. Humph. I have nothing against interdisciplinary approaches, but why don't we figure out what our problem is first? Otherwise, I think we run a high risk of "discovering" our problem is a nail because other disciplines treat their problems with a hammer.

OK, so we don't know what the science of design might be. How will we know when we achieve it? One suggestion is that design will become a science when it stabilizes, similar to the stabilization of mechanical designs after an initial period of radical experimentation. The counter-argument is that anything that's stabilized is science, but is no longer design -- design will move on to stay at the edge in order to continue creating value. Mary Shaw also points out that abstraction, in the form of evolving programming languages, is a form of standardization of design. Carliss argues that value does not go away with standardization, rather it becomes difficult to capture, which is good for the majority since value then flows to all of us. Beyond standardization, how can we harness creativity on a regular basis, without stifling it with templates and formalizations?

Science is about "compressing" information -- finding small representations for big classes of complex behaviours -- while keeping these representations practical for the problems at hand (not "first principles"). Science is not the same as engineering, but according to this guy the panel isn't making a good distinction. What is the difference, especially in the context of software?

There's a difference between "normal design" and "radical design", need to look it up. Apparently, we teach normal design well, but fail on radical design -- which is unfortunate, because that's the really difficult stuff.

Software is malleable, so we shouldn't have a single representation for design?! Mary says you should create notations specific to your problem (DSLs?), but admits that interoperation between notations would be a big problem. Seems to me that this problem has been solved; most people can use UML, or if they prefer can extend it, or build a new language on top of the MOF metamodel that will still retain some basic compatibility with other representations based on MOF.

And here we go with analogies to other fields again... What's the equivalent of a wind tunnel for software? Who cares? Mary would have us look at civil and chemical engineering, Carliss says system engineering (but that's 60% software already), and Michael says we should just look at other branches of engineering in general. Yawn...

Mary would like to predict quality attributes based on a design, sounds like ABAS.

Conway's Law: a design reflects the structure of the organization that produced it. Carliss thinks we should formalize this hypothesis and test it. Sounds fun, though I'm not sure it would be useful.

Two great points from an attendee: first, we need to standardize a vocabulary, second, design is a skill not knowledge.