summary and new start

I reviewed all my blogs of the past a few years – that is one advantage of blogging over private notes: it forces you to face your history of ideas! I found that sometimes I contradicted myself, and I debated with friends, and I changed my mind. The important thing is not the conclusions, but the arguments, the process of arguing, and more importantly, the understanding, insights, and friendship.

OK, another immediate contradiction of myself: Now, I want to have a summary ("conclusions"!), so that we can invent more in the coming year(s).


1. "Philosophy": science and technology, regardless of modern and ancient, are one. The saying that modern science is totally different from ancient science and from technology is a myth. At a high level, they are the same. We can and should use science-thinking ("scientific thinking) in technology, and vice versa.


2. "Time" -- the basic sequence

“Analysis/Design/Coding/Testing” corresponds to “Problems/Theory/Solving Problems using the theory/Testing”.

Note: in "problems", you have both "common data" and "use cases", not just "use cases".


3. "Space" -- the basic structure (or “architecture” -- but I prefer small words in science/logic, instead of big words in engineering)

“Common data” (this leads to "OUR" Object, UI, Relational, and their mappings -- OR mapping and OU mapping) and “use cases”. "Use cases" leads to UI and "facade" -- in Siebel, "business service" and "workflow", they then lead to networking (which in turn includes 4 parts: web service, EIM, reporting, and remote), logging, and security.

Note: “Common data” is a “new” phrase I have begun to use. I discussed/debated a similar topic sometime ago in my blogs, “data model vs. domain model”. I believe “data” is more user-friendly and, well, manager-friendly. I add “common” before "data", to emphasize that the concept has inherently an element of “design”, “structuring”, or well, “modeling”. In short, it is a compromise between “data model” and “domain medel” -- but I still do not like “domain model”: it is too programmer-oriented, not user-friendly. Users are totally confused when you use the word “domain model”, but they know, I mean, really know, “data”. Note that it is not just wording. Inherently, “domain model” has too much “technical” baggage. "Domain model" concept belongs to a more limited technical context, instead of a top level concept that can be used together with the concept of “use cases”.

A special note: I notice that there is a mapping between "time" and "space", or, a common spot in both "time" and "space": the "use cases" (UIs and facades) maps to "testing". This is understandable: the so-called "space" is the basic structure for software, which must follow the basic structure of human logic, which is the so-called "time" all about.

4. Technical team dynamics (or "team culture" or "team leadership" or "team moral" -- pick the phrase you like):

a. Basic estimate of human capability, science, technology, and education: a good high school new graduate or an average college new graduate can start to work productively within two weeks on any computer technologies, within a good team and with good mentoring.

b. Rotating/pro-vertical (avoid single threading) and lean (cut self-enforcing communication overhead)

Single threading is bad. When project is late, you cannot put more people on the bottlenecks. Worse, it damages team moral. It is the basis of unfairness, laziness, and even outright blackmailing. Based on my observation, it is the root cause of more than 80% of problems in IT.

The irony is that out of the 80%, more than half of it is from the “solution” of the problem: heavy communication overhead. It is a self-enforcing overhead -- people first compartmentalize the team, create the hunger for information, and then, they “coordinate”. Gradually a lot of people cannot do things anymore, they only “communicate” and “coordinate” while they are devaluing the whole profession into production-line work, with extremely heavy, costly, error-prone, and misleading overhead. The double irony is that this "solution" actually aggravates the "single threading" problem.

We can do better. We need, can, and should be more effective by being lean. However, to do that, we need to find a better way to solve the single threading issue.

Observing other professional fields, we can find that the real solution is the opposite of the current “solution”: instead of limiting, we expand the scope – every developer should at least have 2 or 3 “fields” (remember that even an average college new graduate can pick up things in a field within two weeks!), then, we can rotate the fields within the team. Also, when we do “division of labor” in a certain project, we should always prefer “vertical” division (end-to-end of a vertical slice), instead of “horizontal” layering division (e.g., one person in UI, another person in Business layer).

c. “Document driven”, meeting minutes, source control, and source control friendly format. The essence of the “document driven” is that all documents, including meeting minutes, user oriented documents, and even “private” or “personal” notes, should be treated as “source code”.

There are two big challenges.

One is that people want to keep some “private” and “personal” notes – this will be resolved by rotating mentioned above.

Another one is “source control friendly format”: some user oriented documents, for example, “requirements” or “user manuals”, are not easy to be put into version control friendly format. Currently, too often they are in MS Word together with spreadsheets, which both are ugly and horrible for version control friendly minds! – This is actually pretty easy to resolve in web technology (wiki etc). I hope the corporate world will catch up on this quickly.

d. “Process” must be simple, and not arbitrary. In more detailed terms: it must be in place before projects. Preferably, its wording should be consistent with common usage in the industry, like "analysis", "design", "coding", "testing", “use cases”, and “common data”.