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.