This one I owed it since a long time.

In the year of 2000, David Cavallo published his article "Emergent Design and learning environments: Building on indigenous knowledge". In this article, the term "Emergent Design" was coined, as an alternative of blueprints. Cavallo indicates that many analysts researching the situation of educational change projects failing, was actually because of the committee-generated blueprint that was created to drive the change. The result was always a reformed implementation of the blueprint that did not solve the problem.

So, Cavallo proposes another "way" of doing that process. He bases his discussion in two innovations: The Digital technology and the Administrative decentralization. Se second one does not change the management practices, but only lowers them to other levels in organization to be distributed.

Now, Cavallo proposes some principles to guide this. Constructionism (Papert, we build knowledge when we construct things), that is based on Constructivism (Piaget, we build upon what we already know). The other ones are Technological Fluency, Applied epistemological anthropology, immersive environments, critical inquiry, long-term projects and Emergent Design.

The idea was to allow children to be immersed in long period projects, so they can handle fluent technological language. With that, the students will start looking with criticism the new understood world, and using the epistemological anthropology the teacher may be able to detect the learning forces of the students freedom and design "on-the-fly" the next learning framework to explode the possibilities.

All this is handled using the emergent design approach. The learner focus on building new knowledge upon the existing knowledge, and the tools and guides are given to facilitate that. Thus, there is no preexisting path, but one that is built as it goes on. It is pure Discovering by Construction.

Now, that is a learning experience Cavallo says it is not the only one possible. It was mapped to software development by Kent Beck, and it is presented as an alternative to blueprints (that is, the dreaded BDUP).

Emergent design is built on top of a Make-Verify-Improve life cycle. Since the new world is not created yet, the developers usually give baby steps, one step at a time. Decisions are not taken at earlier stages, but a just-in-time approach is followed, and developers are the one making those decisions.

This can prove good points:

• Avoids Prediction. Decisions are taken upon knowledge acquired by constructing, when the developers know that it works, and at the time it is needed.
• Verifiable products. The created products are real, working, and thus they can be validated against the requirements. New development is done on top of this real thing and not on top of paper ideas.
• Decisions are backed up by information obtained from feedback of real products and not assumptions.

Still, there are a couple of bad points to mention:

• Refactoring vrs Redesign. Note these are two different things. Refactoring is about improving the code after it works, redesign includes changing what it is done to use another approach or structure simply because the first one does not work. So, emerging design may not be about creating and then improving, but creating and then recreating.
• Late decision at Macro level. The problem with too late decisions are that the ones that affect a level higher that code may require much more amount of rework, recreating functionality in another way. Remember, refactoring is work to improve, rework is work to make it work as it should.
• There is certainly more information (a developer immersed knows more about his local environment than a designer), but there is less higher view to make the correct decision. That is, the grass-level view Cavallo explains work for individuals creating a single knowledge, since that knowledge is ok to be incomplete (there are lots of data the learner will not know). When you have individuals working together, you need a second level view to understand how all the individuals are doing matches together.
• The validation is locally centered. When individuals validate their decisions taken upon the current local value, the isolated solution may work. When integrated, the correct parts may not add up to an integral sound structure.
• It is assumed the individual will make the correct decisions based on information, which requires a long time to acquire (Cavallo’s long process). Thus, initial development is a challenge since no individual has enough info to make certain decisions.

So, those and other pitfalls can be avoided by taking care of tactical and strategic decisions:

• Use guidelines, like principles, to driven the decisions in case of doubt.
• Create from the bones. That is, create on top of a secured and sound base that explains by itself the rationale of the solution. That may require to bring some critical decisions Up Front, always knowing those decision may be changed in the future.
• All decision has to have a rationale that supports it. The idea is that later on, when the decision proves to be wrong, the rationale may help to chose another idea.
• Multilevel Coding. I know this is something not much people understand, but actually defining the global structure, then defining each component using a tactical structure to bind the bones, and finally writing the code to add meat to them, is what I call coding at levels, since every description of the solution is code. This helps a lot to visualize when and how a decision of any level can be taken or improved.

Hope this helps to clarify a myth about Emergent Design: It is not an easy two step methodology of blindly doing and then step back to see what emerged from the disconnected decisions. And, it may not be good for all projects not for all people. Lastly, it not an alternative to architecture, but just another technique to construct the architecture itself.

William Martinez

During all these discussions, in this blog and other forums, I have found some semantic dissonance. This means some people use the same word and even the same concept, but actually understand different things from it.

So, words like architecture and design mean paper to some and process to others; they may be normal, unnecessary or even offensive. This is a little post that tries do define some of the words I use, just to be sure anybody that reads me understands what my meaning is.

Design: As a verb, is the process of decision making towards the creation of a solution. As a noun, it is the one word name of Design Description.

Design Description: The description of the decisions taken toward a solution and their rationale. It can be a document, image or even multimedia.

Code: Sentences, written in a particular language, that describe the solution. It can be at any level, and may (or not) be executable.

Strategic Design: Design that focus on architecturally significant issues, whose majority are global decisions described in an intensional way.

Tactical Design: Design that focus on tactical issues, whose majority are local decisions described in an intensional way.

Micro Design: Design that focus on operational issues, whose majority are local decisions described in an extensional way.

Domain: Is the set of concepts and relations that define a reality. It is not a description, since those concepts may be infinite or unbounded.

Abstraction: Is the result of abstracting: process of elimination of detail without loosing the essence of the concept being abstracted.

Model: Abstraction of a reality from an specific domain.

Modeling: Process of describing a possible reality in an abstraction level.

Architecture: System Structures, the externally visible properties and the relations between them. NOT PAPER.

System: Independent structure of components interrelated.

Software Intensive Systems. Systems where the majority of the components are software based ones.

Solution: Part or whole of a system that solves a problem from a domain.

Meta something: Meta means beyond, above of, self-referring. Using those concepts of the suffix, we may say meta-modeling is modeling models. Meta-data is data about the data. Meta-language is a language that allows us to describe languages. Meta-comments are comments about the comment. And so on.

Now some notes: from the above, we can say interesting things. For instance, modeling is not a paper generation process, but a description process. Modeling can be use to describe a solution, thus it can also be interpreted as coding. And code, it is not just writing executable lines (in fact, they are not executable, they need more work).

When time and other discussions require it, I will be posting more glossary terms.

William.

Working with developers, I often found them thinking of design as a generic word to indicate "sketch the classes you are going to create".

Of course, I don't share that definition. I think of design as:

"composing the sentences, in a particular design language, that describe the solution of the problem"

That said, I add that there are several design levels and types. That is, you may find out you are designing when you think you are doing something else!

Amnon H Eden and Raymond Turner had some publications where you can read about a proposal for an ontology (using the Intention/Locality). Part of their definition is that the software design should be divided into three categories: Strategic, Tactical and Implementation.

Of course, Strategic design sentences are those for Architectural design, where decisions will impact the whole. Tactical sentences are what we have always call the design, where the focus is local to one part of the problem, and that is abstract enough to be variable. Then the Implementation are sentences that are local, but also the actual execution.

That last one I call Operational design. I also call it Micro Design. That design is the one the developer does when creating the sentences that define the executable solution. Note that the decisions here are also important. Note also there are design patterns to this level too, that are different depending on then selected language (those are called Idioms).

There is another point to this definition of design: We can describe a solution at different levels, and it will be the same solution. The good point here is that each level is an abstraction of the lower level, where details was taken out of the way to clearly see broader requirements. Not all designs can be executed, and not all levels may have all the required details to be able to execute as it should.

Funny, huh?

William Martinez