The result of lavishing all our attention on implementation is that we have a field with millions of implementers but no designers, and we often leave the most critical decisions (about what the specification should be) to non-technical people.
I'm not a researcher but I keep a research agenda to give a direction to my career. This agenda guides my self-directed learning and help me filter and organize information.
When developing software, we do two things: (1) we specify the behavior of a software solution to a real-world problem and (2) we provide an acceptable implementation.
My research agenda is based on the belief that we need to move the focus of software engineering away from the formal representation of programs and towards the design of conceptual and adaptive solutions to real-world problems.
While most of the cost of software projects is incurred after the software was released, the industry is still focused on the initial development of the software. As we implement, test, and use the software we ultimately learn things about the problem or about the system that we wish we had known during the design phase. This is one of the reason our industry adopted agile methods. We want to release the system as soon as possible to learn and include this learning into the next design.
However, I don't think production code is a good medium to think about our solutions and the design of our systems. The performance requirements and characteristics of the platforms the software runs on will always lead to some accidental complexities. We need instead an environment that will allow us to (1) build runnable models of our solutions in the problem domain, and (2) automatically translates the design into production software.
Some systems have been built this way but their problem domain was software engineering itself. For example, a LISP interpreter is a runnable model of the language. The designer can explore the design space using a small, but inefficient, model. Similarly, thewas designed and simulated in Smalltalk. A translator was written to generate the C code for each platform.
The rest of this page is a collection of ideas related to this goal. This is still a rough draft.
Fundamentally, the software designer is a model builder. The programs we write are detailed formal models of an implementation of our solution. As explained above, we also need a runnable model of our conceptual solution so that we can explore the problem. We also need models of our systems in order to change how the final solution is going to run.
Conceptual Design of Software
A conceptual design is a description of a software as a network of concepts. Those concepts are chosen, or invented, to solve the user's problem. This design does not describe how the software is going to be represented in the machine or how it is going to look like to the user. This design is focused on how the software works.
This is not a new idea, in, Terry Winograd collected essays on the conceptual design of software.
Theat MIT is working on the conceptual design of software. The best introduction to their work is probably the article by Daniel Jackson " ."
Historically the industry has been focusing on algorithms and programs. I believe that we also need to look at our software as complex systems and use the methods and tools to deal with this kind of system.
A complex system is a system made of a large number of parts that interact in non-obvious ways. When designing or dealing with complex systems, coupling and modularity are important concepts because they directly impact the ability of the system to evolve (learn).
In Notes on the Synthesis of Form, Christopher Alexander represents the design process as as a complex system and shows why the system needs to evolve subsystem by subsystem.
The software organization is a complex system as well. Systems Thinking provides a set of ideas and tools to help us steer organizations in the desired direction.
Science of Design
We're still designing software systems the way Babylonians were doing mathematics—with a collection of best practices and design principles. We're still missing the theories that would allow us to scale our artifacts to higher levels of complexity and make the design process more repeatable.
The science of design is a relatively new field that looks at methods to make the design process more rationale. There will always be a part of design that requires creativity and ingenuity. However, we need better thinking tools to control and enhance this creativity.
In "Notes on the Synthesis of Form", Christopher Alexander presents a design method based on a functional decomposition of the problem.
In Design Rules, Baldwin and Clark shows that "the design structure of an artifact and the task structure of the design process are isomorphic."