why UP is important and why use cases are not

[Update from my later perspective: I guess this is the point that I begin to take pieces of “process” and reduce it as (trivial) engineering item. Eventually, I believe “processes” can be reduced as software architecture (engineering), economy, or, politics; I also believe this is the spirit of “lean” process: pay attention to “things themselves”]


Vikas has a very good post here:
http://vikasnetdev.blogspot.com/2007/01/pragmatic-programmer-my-rating-55.html

http://www.pragmaticprogrammer.com/ppbook/index.shtml
http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/sr=8-1/qid=1170022962/ref=pd_bbs_sr_1/104-6032710-2825522?ie=UTF8&s=books

It prompts me to put some comments there and put more comments here:

1. Why UP is important.

I see the contrasting directions Vikas and I are emphasizing in the past and present. It seems that Vikas is now emphasizing more on TDD, while I am emphasizing more on UP.

I believe Vikas’s order (UP first; then, XP) is a better approach. Somehow my steps (XP first and then UP) are not “logical”. However, there is a good thing out of it: as a result, I explicitly noticed something that it is worth it to document here.

The reason of emphasizing UP is that I have gradually realized that a lot of people, both mangers and developers, treat software process as a management common sense, instead of an engineering domain. They have no clue (sorry for the bluntness), yet they can talk like they know, because of the apparent similarities of basics. I want to de-emphasize the “common sense” aspect. I understand there is a “common sense” aspect, and there is a “top-down” (i.e. business oriented) approach for the “process”. However, now I want to emphasize the fact that if a person does not know object oriented programming (English talking does not count; and VB6 programming does not count), then, he/she is not qualified to talk about modern software process. They need first to study and learn, and UP offers an excellent tone and context for that kind of learning. Modern software processes depend on serious OO experiences.


2. Why use cases are not

One thing I especially want to augment the points in “Pragmatic programmer”.

It starts with the “requirement pit”: “Don't Gather Requirements—Dig for Them” -- it is very true. Developers, working with users and business analysts, need to help to define the new business workflows. They do not just “gathering”! In order to do it, you have to “Work with a User to Think Like a User”.

I agree with all those totally and I have nothing to add there. However, the book did not do a thorough work on “how to document requirements”. It mentions “use cases”. To me, it is scratching itch through shoes. It also mentions “Sometimes the Interface is the System”. It is so close. However, it is still not there, yet.

In my previous posts, I put together a “user manual with glossary—spec—test script—user manual with glossary again” approach (By the way, the book also indicates the importance of a “glossary”). It is basically the “storyboard” method used in the industry; however, it add things in the perspective of a “user manual” (so, you must think like a user) and a “test script” (so, you can have some “example data” in the document).

To make it clearer: please discard the famous “use case”, for two reasons.

On the one hand, it does not have screen mockups -- it does not help to get users involved. For most business applications, without mockups, it means absolutely nothing to users. Without mockups, it is inevitable that there will be a lot of ambiguities and there will be huge misunderstanding. “Glossary” will help; but it cannot help without mockups. Without mockups, you are inviting disasters to happen!

On the other hand, those “preconditions”, “failure end conditions”, “success end conditions”, “extensions”, “variations”, they can be covered by the “behaviors” (or “logic”) of the buttons in the mockups. Every programmer knows them – they are big words for the trivial things: ordered steps; if-else; loop – give me a break! Who does not know them?!; every power user also intuitively knows them (again, they are just trivial logic 101). Itemizing them into sections makes things so unnatural that they block the discovery and defining the inherent logic.

As a result, it is not just adding “mockups”, we need to remove those “use case” signature items. Of course, we can use “user cases” as a general concept, to refer to the “flow” aspect (the other complementary aspect is the “entity” aspect, which starts with “glossary”).

18 best practices from a systematic study of UP and XP

18 best practices from a systematic study of UP and XP

Recently, I studied literatures about software processes. Several years ago, I had studied them carefully and intensively for a while. After that, I did the "practices", but I did not follow the literatures anymore. Since then, the landscape has changed a lot. At that time, all processes were converging to UP and XP; now, almost all of them are variations from UP and XP and trying to "add value" to them, and UP and XP are going toward each other also. However, the core is still UP and XP. It is so because UP and XP are different enough, so that together they cover all different ideas and practices.

I feel I need to make a point that before we take sides on processes (the heavier or the lighter), we need to study literatures and do the practices on both sides. Then, very likely, you will find that they are not conflicting, but complementing.

Further, during the process of reviewing those literatures, I feel I need to do two things simultaneously: I want to simplify them into one sentence so that everybody can understand them immediately and participate (the skeleton part); I want to enrich them to such a degree that it deserves true respect as an engineering domain (the flesh part).

(a) The skeleton part of a “software process” is the waterfall of analysis, design, and coding-testing, with iterations. That is it – of course, more accurately, that is the core of it -- you can always add more items like deployment and support.

(b) The flesh part of a “software process” is the “best practices”. Note that I prefer the word “techniques” – because there are full of trade-offs, and “best practices” are just too pretentious for my taste. However, “best practices” is the wording the industry likes. In both UP and XP, there are “best practices”. In UP, there are 6; in XP, there are 12. All together, there are 18 best practices, listed in the following:

(i) (UP, analysis) manage requirements

(ii) (XP, analysis) on-site customer (this does not exclude using “user manual with glossary--spec--test script--user manual with glossary” documentation. Note that “user manual with glossary” is the beginning and the end, which means “storyboard” should be used in the very beginning, not until “design”: mockup screens are not design, they are analysis.)

(iii) (XP, analysis) planning games (to estimate quickly, we need "analysis patterns" based on the "glossary")



(iv) (UP, iterations) develop iteratively

(v) (XP, iterations) small releases

(vi) (XP, iterations) continuous integration

(vii) (XP, iterations) pair programming (i.e. continuous design and code review)

(viii) (XP, iterations) sustainable development (this is both the result and the ultimate motivation)



(ix) (UP, design) use component architecture

(x) (XP, design) simple design (it should be among well-known "architecture patterns" -- it is “simple” simply because it is well-known)

(xi) (XP, design) metaphor (it is so simple, i.e., well-known, that one word is enough; hence "metaphor")



(xii) (UP, coding-testing) model visually (note that this belongs to "coding-testing", because the emphasis is to do it deep to the mechanistic design, i.e., at the "design pattern" level, which is within coding activity for modern higher-level languages like java/C#/VB.Net)

(xiii) (XP, coding-testing) refactoring (it is hard-core bidirectional "model visually")

(xiv) (UP, coding-testing) manage change

(xv) (XP, coding-testing) collective code ownership

(xvi) (XP, coding-testing) coding standard

(xvii) (UP, coding-testing) continuously verify quality

(xviii) (XP, coding-testing) testing



Note that it is so nice that UP uses verb-noun phrases, and XP uses noun only. In the "best practice" perspective, UP is more high-level, and XP is more hand-on and know-how oriented. They mix and complement with each other perfectly.

The content in the parentheses for UP and XP are my "re-interpretations". They make UP closer to XP, and make XP less extreme. Also, in those re-interpretations, I introduce “analysis patterns”, “architecture patterns”, and “design patterns” to their right places. I believe those re-interpretations are crucial to make things right.

There are so many of them! If you ask me to pick the really important ones, I would say, they are (ii) and (xv) – when things are really bad, you start from those two. After that, it all depends. I know, you may be surprised that it is not "testing": it is just reality that a lot of times, the situation is so bad that you have to take care the more rudimentary things like the opportunities to talk to users and where are the most recent source code!


(c) The relationship between “best practices” and “8 core programming techniques”

(i) From the “design” part of the “process”, we have “8 core programming techniques”.

(ii) However, it is important to understand that the relationship is also “bidirectional”: from “8 core techniques”, “unit testing” is the natural “wormhole” to link back to the “process”. "Unit testing" introduces the "user manual with glossary--spec--test script--user manual with glossary”; it also “naturally” links to refactoring, coding standards, and collective code ownership.

(iii) But “unit testing” is not the only “wormhole”. The existence of both “database” and “screen” in “8 core techniques” provides a foundation for the parallelism of "business workflows" and "domain concepts (glossary)" in analysis.

(iv) Understanding the back pointer “wormholes” is important for developers, because their “home world” is the “8 core programming techniques”, not the “process”. However, they need to visit "process" once for a while.

Windows Vista and the 2007 Microsoft® Office

Just pick a city:
http://msevents.microsoft.com/cui/EventDetail.aspx?culture=en-US&EventID=1032316062

This link perhaps will disappear, so, I copy/paste something here:

....The release of Windows Vista™ and the 2007 Microsoft® Office system ushers in a new age of application platform development. Join us at the developer track, hosted by MSDN Events, as we explore the new capabilities and features that will let you....

There are 5 sessions....

Isn't that exciting?!!! This is definitively a new age: XP is the negatively so (OK, do not be sacred of “negative”, it is a good thing, it is the removal of the win 95 baggage), Vista is the positively so – this the first huge step …

Let’s see Linux and Java …

The scary thing is that Office is more and more part of the OS (not financially, of course). So, Linux and Java will be more and more difficult …