Detailed communication and Design

Detailed communication and Design


Software development is not manufacturing, there is no the dichotomy between “design” and “production”. The whole thing is “design”.

I know the above for a long time. However, it is more and more difficult to keep the belief -- because of outsourcing (I do not see any other real reasons), programming is more and more perceived as cheap labor, instead of a professional activity. As a result, I am more and more thinking about the meaning of “design”. Also, because the essence of RUP is aligned with “manufacturing” thinking (I know, this is a big generalization), I think more about XP’s “design”. However, although refactoring puts “design” in the center, the general perceived theme of XP is “less or even no design”, so, it is really disappointing. Then, we have DDD. I am very disappointed of it (see my previous blogs); however, the fact that it puts “design” back to the center of everything is really a wonderful achievement -- by using “modeling”, it changes “requirement gathering” into “design”. So, now “modeling” and “refactoring” extend “design” to everywhere.

However, it is still not enough -- it is just a starting point: we all know the waterfall sequence of “analysis-design-coding”; if we admit that everything, including coding, is “design”, then, what does that sequence mean? Are we ready to throw the sequence away, or, does it still mean something?

I believe the sequence still means something. The following is the reason.

-----------------------
Business applications are complicated. The complexity is not from the inherent difficulty, but from the sheer amount of information that cannot be obviously modularized or abstracted – any abstractions higher than higher-level languages (Java, C#, VB, C++) will always be leaking abstractions.

This is the root cause that we need detailed communications, because every detail counts.

However, for communications between users and developers, even for teamwork communications among developers, higher-level languages are simply too detailed to be effective.

As a result, we need various ways to “simplify” it, to make some leaking but helpful abstractions. Those are the “designs”.

Notes:
(a) There are “various ways” for design -- you can have many ways for design.
(b) This perspective paints design as “not the real thing”, this is the XP perspective.
(c) However, it also points out that it is the critical “handle”; it is the center of everything! We cannot talk code line by line; we have to talk refactoring, which leads to design itself. Also, just like higher-level languages in “coding”, natural languages in “analysis” are too detailed for effective communications. As a result, we have to talk modeling, which leads to design itself.
(d) You cannot change "analysis" and "coding" only for communication, however, you can change "design" for communication. As a matter of fact, that is the very reason that we need "design" -- wow, what an insight!
(e) Design is the key for teamwork. Perhaps you can get away without design if you develop it for yourself and by yourself; however, you need design when you have “users” and “co-developers”. In short, if you need to talk in development, then, you need to design!