What is Design?
I see many discussions get heated or go in circles when the topic is “design.” In the field of software development, what is design?
There are those looking at it from the point of view of usability and fitness for use. Some, often closely aligned with these, use the word “design” to talk about the visual aspects. Others, the user experience.
Others look at the manner in which the software is constructed. Those who use the title of “Software Architect” often look at the big picture aspects–what frameworks will be used and how the system will be distributed. DBAs look at the schema of the persisted data as design. Those who write the code see design in the modules, classes, methods and functions–and how they interact.
Some people think that design is something you do before building the system, often drawing diagrams to illustrate their ideas. Some go so far as to assert that if this is not done prior, the system is not designed at all. Others maintain they can do just as well designing on the fly, mostly capturing the design directly in the code, but also describing it in conversation and sketches. Still others say the real design is “as built,” and the original intent is not so important.
People use “design” to refer to all sorts of small tidbits in the development process. They abstract some of these and call them “design patterns.”
Sometimes people use the word “design” to mean “the important stuff I do while I leave the mere implementation to others.”
All this is just about software, and is surely not exhaustive. When you add physical products to the mix, the definitions multiply. Any discussion about design that doesn’t develop a shared understanding of what is meant by “design” is sure to cause difficulties. And public utterances about design will always be interpreted differently by some people.