UP is the best tool to prevent from creating a VB6 mess

UP is the best tool to prevent from creating a VB6 mess


To prevent from VB6 messes, we still need to use XP’s techniques; however, the foundation must be UP – UP is the best tool to prevent from creating a VB6 mess

To explain the title: I have been using Java for a long time. To me, VB6 is a “friend” for correcting UP’s heaviness and creating a lightweight process. So, I have been overly nice to VB6 culture. However, the more projects I worked with VB6 teams/developers, the more I know the dark side of VB6 culture. I developed some techniques to correct VB6 problems, using UP, hence the title.

You may say I am just sitting fence between VB6 and UP, and in between there is TDD. In a sense, it is the case. However, when I am in a VB6 crowd, I would never say TDD, I will always say UP, because if you say TDD in a VB6 crowd, you will get lost every quickly: the differences are crucial (or even fatal!), but are so subtle, it is really too difficult to lead. If you use UP in a VB6 crowd, then, everything is clear. You can correct problems before they emerge, or, at least when they are just emerging.

Why the foundation must be UP? -- Because of documentation (more specifically, one-core-document documentation), use case analysis (with activity diagrams, and with mockups), and class diagrams (and state diagrams).

(a) Documentation is important: “documentation driven” is the only way to prevent chaotic mess. Note that even sometimes we get lucky and the project is a success, then, the product is in the hands of only one or two developers. That situation is not good for the team and the company.

Why one-core-document is important? -- Because passive “traceability” is not enough, we need relentless “synchronization”. That is, whenever we have changes in requirements, we need to synchronize them with design, code, test, and support. Reversely, whenever there are changes in support, test, code, and design, we must change requirements. I noticed that the reverse part is not understood by most people, they feel that requirements are from users, and therefore they cannot be changed. That is not true. Requirements must be discovered, modeled, and analyzed by analysts/developers, they are must be synchronized with other parts. The easiest way to enforce synchronization is to maintain only one core document.

(b) Use case analysis is important. Perhaps surprisingly, the key word here is “analysis”; however, “use case” defines the techniques of how to do the analysis. In the past, I emphasized using “mockups”. I still do. However, in the process of communicating with VB6 programmers, I found out that the key is “use case”, not “mockups”. In other words, if I only show them how to do the “mockups”, VB6 programmers will learn that very fast, yet will never really “get it” and therefore will create problems in practices. The problem is that they tend to believe it is “design”, so, they either get into UI details too much, or, they skip the analysis at all. Either way, they will just write a few lines of “requirements”, then, jump onto tiny details. After observing and solving the messy problems many times, now I know that I must emphasize that “requirement gathering” is not just “gathering”, it is an “analysis” process, and the technique of the “analysis” is “use case”, using mockups, and sometimes activity diagrams.

(c) Class diagrams. In the past, I emphasized that ER diagrams were fine. I still do. However, now, I emphasize class diagrams, because when you use ER diagrams, you mean to use them as a domain model, not just database schema. In other words, ER diagrams are only a convenient substitute of class diagrams. In the same line of reasoning, class diagrams are more compatible with state diagrams. However, I do want to point out that you can express states in tables also. So, really, it is more conceptual and “political” than real technical. However, conceptual and “political” thing can be very important, otherwise, you will be in VB6 mess before you know it!