Architect's Thoughts

Prior the Internet days (some people talk about prior television), we had different villages, local ones, with no communication. Now, we live in a global village. We need to communicate and share knowledge, even in different languages and cultures. Furthermore, we learned it is not just us and the "my limited world", but any thing we do affects the globality.

Now, when working on a real world problem, working to find a solution of course, we need to communicate and all or our work is to complement the one from others. There is no one single person that fights all the villains and the rest of the team observes and cheers.

Solving a problem with a software intensive system, involves working with all parts of the system: Hardware, Software, people and processes. No one lives alone with its computer, everybody interacts with all the other components of the system, and the developers are part of that system too!.

Making sense of that, the strategy of working only in my local line forgetting there is something beyond that, goes back to the local world and denies globality. Does it mean you need to work all at the same time? No. It means you work in your local line knowing there is something bigger of which that line is an important part.

What does this matter in Steve Yegge’s post about NOOBs? Well, going extreme, the post indicates there is much waste, fat we need to remove to be healthy. The comments, even the modeling and describing language structures are needless for the seasoned, non-noob programmer. I agree, as long as the programmer is working in a system that has only two components: the programmer and his lines of code.

Unfortunately, that is not the reality. A system not only requires the work of many other components, some non-software and some non-programmers, but also requires all those components to communicate at design and execution time. Robert Martin once said that one of the software functions is actually communicate with people, readers that may have not participated in the development. Does that mean the comments should stay? Not exactly, but that the code itself should be readable, understandable.

One way of doing that, for the development group, is using sentences that make sense and do the function (you can scramble the sentences and do the same thing but being not readable).

Globalization in the System means all components will need to communicate and work with other components. Creating the product with those characteristics, because they are needed, is not being NOOB, but being aware of the fact the software is not an island.

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.

Paul pointed me to a TSS post I missed. Steve Yegge posted some rants about complexity and got to a conclusion about the how good and clean are scripting languages (Portrait of a NOOB ).

I couldn’t post a comment to it, since it was already closed to comments. So I guess I will answer here.

In this first part of a response to that blog, I will reproduce the post I did to TSS. Probably nobody read it since I posted it one month later.

First, let’s summarize Steve’s post (or what I understood of it):
1. Comments are metadata. Metadata is of no use for the compiler, so it can be get rid of.
2. Noobs are comment obsessed creatures, thus metadata enthusiastics.
3. Modeling is a way to comment intention of code in code language itself. So modeling a metadata creation process.
4. Teenagers are obsessive modelers.
5. Classes and in general OO, are metadata in code itself.
6. Static typing is also metadata since the real thing is memory afterwards.
7. Seasoned Programmer is one enlighten creature that does not use metadata, and thus can see the real thing when coding, not ethereal domain models.

What do I agree with:
Metadata is useless for the compiler. True.
Modeling is a metadata creation process. True.

What do I disagree with:
Metadata (at least not all) is not useless. Metadata is important, although not for the compiler.

Probably one of the things Steve Yegge misses in the post is that a language has much more than just telling the compiler what to do. In the DSL post, we talk about languages oriented to one specific domain, using vocabulary and grammar of that domain only. The idea is languages are there to help you solve a real life problem, not to help the compiler. Languages are for you (and your peers), not for the machine. And maybe not all languages are meant for a computer to read them.

Furthermore: Lack of metadata does not mean better code.

Pages: 1 2

In a presentation by Cedric Beust and Alexandru Popescu at QCon San Francisco, about "Designing for Testability", called "Next Generation Testing", and in his post, Cedric talks about "Test Driven Development" (TDD), and does not talk to promote it.

Actually, he does not talk against it, but simply questions about using it, as if it is a good idea or apply-able to all cases. Cedrics points several problems of using Test-Up-Front technique, and one of his lines is: "Promotes micro-design over macro-design". Follow me on this...

Let's change the last D from Development to Design. A Test Driven Design is that one that is accomplished by basing the decisions on the test (The principle may read: follow the option that is best testable). No one is saying when to test, nor if you create the test before or after the actual coding. We are actually thinking on design, and taking into account one -ility: the Testing one.

Now, from my post about the design levels, (and here is what drove my attention over that Cedric's line), the term "micro-design" is defined as the design decisions the developer makes during the implementation of the "tactical design". Those design decisions should be in accordance to the tactical design, and those should support the strategic design.

Here, the question is now if the Test Drive Design is driving a design level that is not the micro design! Tests, if we talk about Unit and Functional tests as I think TDD means them, are a developers level thing. They, in this case, should drive Micro-Design only, and should never drive other design levels.

Let me explain it in other words: TDD shouldn't tell you what classes to use, which artifacts (queues, files, etc) or which relations between functional units there are. But it may help you decide which call sequence to use, which functions should a class have, which structures to rely on. Those are micro-design decisions, that may later on be refactored.

TDD, used at micro-design level will help define interfaces, improve cohesion and even enforce encapsulation and information hiding (if used correctly, of course, since we can create tests that violates all those best practices). But that is when the developer is creating the operational level descriptions (code). There should be a tactical design in place before doing this. And there should be an strategic design in place before that. We can use the testability to drive some decisions at those levels, but they cannot be the main -ility at all.

William Martinez

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