Use "rules" and "non-typical implementation strategy" to replace "use cases" and "common data" respectively

Use "rules" and "non-typical implementation strategy" to replace "use cases" and "common data" respectively

For a technical team, the concept (or “wording”) of “rules” is better than “use cases”, because “rules” is more technical. Users are more attentive and more tolerate to details. It is more "cut to the chase". Note that I correct myself of my previous blogs. Now, I believe the concept of “rules” corresponds/replaces to “use cases” (for technical teams), instead of replacing “common data”.

For a technical team, the concept “implementation strategy” corresponds/replaces the concepts “common data”.

Note that “rules” and “implementation strategy” are more “mixed”: “rules” has “common data” factors, and “implementation strategy” has “use cases” elements. However, their respective “starting point" is “use cases” and “common data” respectively.

I know, it is very confusing, but it is actually simple in action: for a technical team, always have a list, with “rules” and “implementation strategy” as your cheat sheet, then, you will be safe and can proactively respond everything.

Just one more bit of details. Usually there are too many details, too many “implementation strategies” – i.e., the list can be too long to be effective as a “cheat sheet”. So, the secret is to scan through the common, usual, routine “implementation strategies”, and, identify those uncommon, non-typical ones.

You may ask, what are the criteria of “common” and “uncommon” (i.e. “special”, "non-typical") ones? Easy, the 90% rule (I know, usually people say 80% rule – but in technical areas, we need to be tougher).

Of course, to pay attention to the non-typical ones, you have to master the common ones first, even most of the time, you do not need to do them yourself, since you only pay attention to the non-typical ones – it sounds like a paradox, but that is the secret of delegation or helping others to help yourself – that is actually your value as an experienced professional.

thumb typing is good for IT professionals

Diagrams and spreadsheet are bad, plain text is good, and therefore thumb typing is good for IT professionals

The key is, drawing is not that important. If drawing is really that important, than, thumb typing is useless, we neither have to use tablet, or, paper.

I find that drawing is not that important. Diagrams are totally overvalued. After all, the general computing thesis is that what you can describe, you can realize it in computing, it is not that what you can draw or clicking. For software engineering, structure English (or structured any natural languages) is the king, not diagrams, not spread sheet. Whenever you find your documents are mostly diagrams and spread sheet, you should treat it as a red flag, something is wrong.

It took me so long for me to realize the importance of thumb typing. I will strongly recommend to everybody in my family to begin to use thumb typing.

I know young people have been doing the texting for a while. However, I am not talking about texting. I am not that generation; I am not interested in texting. Frankly, I believe it is simply temporary anti-culture, combined with the temporary limitation of computing devices – I am talking about those texting abbreviations – BFF, best friend forever, what a heck!

Even in thumb typing, I prefer the whole wordings. To me, using not absolutely common abbreviations is a sure indicator that the author is inconsiderate and therefore not professional, period. I know, this does not mean too much to a teenage. I totally understand, believe me, I was young before also :-)

I also know a lot of business people have been using PDA for a long time. However, I am not sure most of them are using them to take notes.

As a result, although it took me for a while to plunge into thumb typing, I believe I am still among those not too many people who have recognized the value of thumb typing and are doing it seriously.

[OK, after I wrote the above, I googled thumb typing, and I found a lot materials, see below. Some of them were written in 1999 -- it means that I am soooo late! However, I can still say that those are pioneers. From what I have observed, I am not that late to use it as an everyday routine notes-taking device to replace paper-based notes-taking
http://www.blackberryforums.com/general-blackberry-discussion/800-blackberry-thumb-touch-typist-guide-typing-60-wpm-without-looking.html

It says a lot of things, but all I feel I really need to know is the fact that "we can": it is possible to use thumb typing to think-write, and there are two other tips:

a. Note the left thumb holding Num can give you a Uppercase for the right thumb.
b. When typing number, left thumb holding the Alt key, and right thumb push the number keys.

---Just type the quick brown fox jumps over the lazy dog.

---I will try more aggressively to be able to do blind/touch typing with thumbs.
]

Also, I want to share that, in the beginning, on blackberry, I just send myself emails as my notes. Very soon, I found out that it is a bad idea. I cannot find my notes! They are buried in those emails.

Now, I am using “tasks” to take notes, and periodically “select” and copy them to emails as a backup. Of course, now, “tasks” is my first icon on my blackberry.

There is another thing that sucks. The company has a group security policy: the blackberry locks itself after several minutes. I have to enter password to unlock it every time I need to takes notes. I tried to ask them to make the timeout longer, but you kow the result, Sigh.

For blind/touch typing, I am not sure whether I need a physical keyboard or a simulated one. I am using an old blackberry. The new blackberry model is like an iphone, with larger screen, but a simulated keyboard. I do not have the new model, I guess it is a blessing for typing.

thumb typing all the time -- on blackberry for to-do-item notes

Thumb typing, or, thumb-and-index typing, is not that difficult. You can do that pretty fast after a few hours. The problem is the software – there is no auto-spell checking, and no auto-correction in blackberry (perhaps I missed something).

Thumb typing is faster than writing pad and real time recognition, but I guess we need both, because we still need drawing. Mouse drawing is not good. Touch screen is useful here.

Anyway, thumb typing is worth it. I know, I am slow to pick it up, but I will begin to really do thumb typing on my blackberry to make notes, instead of using pen and paper.


This means I will use thumb typing all the time. Note that I have electronic notes that I take in VIM (not MS Word, since VIM also have spell checking – it does not have auto-correction – or I should say I am not using that, I am not user whether VIM has auto-correction or not). Those notes are detailed, and have a lot of content – that is why I use electronic notes for them long time ago. I always laugh at my college who are still using papers to do those kind of notes. It is amazing, a lot of them still doing that, make notes on paper!

However, I have been using paper doing the to-do-item notes all the time. This kind of notes, they are short, just a reminder. Also, they must be extremely portable, not limited on computers.

Now, I am going to move this to blackberry. I cannot draw anymore, but for those to-do-item notes, I do not do drawing anyway.

Note that I blog this, because I believe this kind of thing is important for computer professionals. Too many computer professionals are too behind on using computers!

Personal Paperless Evolution: Use more laptop, printing pdf on paper, and thumb typing notes

As a new year resolution, starting now, I will always use electronic notes, instead of marking the notes on the margin of paper materials -- this means paper material will officially disposable at any time.

Today, I cleaned up my paper materials, there are only a few of them, I will gradually move the notes to electronic notes. They are not critical, I have already been doing this, it is just a "clearing house" activity, I guess.

More explanations:

1. The key of doing this is to use my labtop more often (the battery is OK, I just need to stop my bad habit of prefer reading paper materials and making notes on them). When I travel or at home, I will use my blackberry and my kindle more often -- even when I have to use paper material (OK, I still prefer reading on paper than on computer. Kindle is fine, but Kindle cannot handle pdf), at least I must use thumb typing on blackberry or kindle to take notes.

2. As mentioned above, Kindle is a big disappointment to me, I was hoping it can help me to realize the "paperless revolution" in my "home-office" and my personal life. It did not. Now, I have to re-do it by an evolutionary approach.

Now I know, a "reader" should be have larger screen (perhaps by folding it or better bending it without the middle dividing line) so that it can handle pdf without any reformatting. It must be touch screen with stylus support to avoid thumb typing. Also, it should have a fold keyboard for typing. In short, it is a tablet computer with an electronic paper screen.

I almost regret of buying Kindle, I should have gone to iLiad 1000, which has a price tag close to $900. However, the screen of iLiad is still small and not convenient for typing (does it support external key board? not sure); futher, it does not have color, which is important for some business documents. Also, it does not support video.

This leads to a question, why epaper screen? Because it is easy to eyes, and it saves battery -- both are not that important for business documents.

So, after all, I guess for pdf documents, let's keep it in labtop (or tablet - if you have it); for "ordinary" books, use kindle. So, I guess my decision on Kindle is an OK one, although Kindle is indeed disappointing -- the technology is slower than I expected. As a result, we need to adapt to the current status of the technology. Printing pdf on paper (sorry, trees, we still need to cut you!), and thumb typing.

Summary of 2 "blocks" and their sub-blocks

Summary of my previous summary



I will do things according to the following 2 "blocks" and their sub-blocks:

1. “Common data”: this leads to "OUR" Object, UI, Relational, and their mappings -- OR mapping and OU mapping.

2. "Use cases": this 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.

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”.