Design Approach Tina

This is to describe my typical approach to design. I called it "Tina" for lack of a better name.

My (non-XP) approach to projects generally goes something like this:

  1. Collect information from users and/or requirements docs by studying their work process, existing system, forms, etc.
  2. Study information and gather new questions that arise from study.
  3. Ask the users those questions
  4. Form a rough design using screen samples, report samples, menu layouts, etc.
  5. Get user feedback on rough designs and samples
  6. Implement a small portion
  7. Get feedback on small portion to see if we are close
  8. Continue with more parts, getting feedback periodically
  9. Do a systems-wide test with users when all major parts are completed
  10. Make adjustments based on systems-wide test

The user is "bothered" the most in step 1, and progressively less in 3, 5, etc. Thus, their input decreases over time (unless there is a big problem that arises). Step 6 and 7 are mostly to make sure that the "look and feel" (conventions) are satisfactory to the user. If they can use the parts by themselves in production, then a system-wide test may be irrelavant.

(Note, I recently added the system test, and removed "draft schema" because users usually don't see those, although other developers might.)

Is "Tina" BigDesignUpFront?. It is, for the following reasons:

The iterative nature of steps 6,7,8 may be agile, but if there is a relatively large amount of design work done before any coding, then that is BigDesignUpFront.

Putting on my XP hat, I'd say that one big concern about "Tina" is that user input decreases over time. XP advocates the opposite. Also, "Tina" makes the developer figure out what it is that the customers want, whereas XP makes the customers tell the developers what they want.

I'll point out that DesignApproachTina is pretty close to what I usually have to do, not because I want to, but because managers and customers seem most comfortable with it. The idea that users shouldn't be "bothered" is a bad idea, as is the idea that anybody can provide any useful feedback after reviewing "designs". XP's emphasis on continuous feedback and real working code is very attractive to me, and I wish I could find some clients who would agree.

If user feedback was a free and unlimited resource, sure, we would all bathe in it.

Re: This is not clear from the description, but it seems that implementation tasks are intended to realize pieces of the overall "design".

I am not sure what you mean here.

What I mean is that there is a "big design" created first, and then developers implement the system based on that design. This is in contrast to XP and other processes that instead focus on one piece of functionality at a time.

Re: Also, "Tina" makes the developer figure out what it is that the customers want [instead of customer]

I am not sure why you have this impression. It does not state that.

Steps 1-3 seem to imply it. The developer does a study of customer processes to determine what is needed.

Overall, Tina works in my observation, if analysts have sufficient experience and skills (XpIsForBadPlanners). It is a waste of time for users/customers to sit there all day and watch you make dozens of similar CrudScreens after they have seen the first few. Generally they will not have much feedback beyond the first few until the system-wide test is done. There is little need to bother them during that lull before system-wide test.

I don't think anyone claims that Tina doesn't work. You asked whether it was BigDesignUpFront, and I think it is. Steps 1-5 are "big design", although maybe you don't go too big.

Somebody please tell me why certain Wikizens insist on using "big design up front" the way most of us would use "dog turd." What are you on about? To quote the XPers right back, if it works in a real situation why are you complaining? Up front design has saved my bacon on more than a few occasions, and I continue to use it because it's the only way to Get The Big Picture® in place before generating problems for myself. Please don't assume that every design that has been done "up front" has some fatal flaws. That simply isn't true.

{I try not to take it personally. The ability to use one's experience and smarts to design up front instead of organically and wastefully starting everything from scratch each time is a badge of honor and the root of technology: standing on the shoulders of the past's lessons. XpIsForBadPlanners in my opinion. Experience rocks.}

See the BigDesignUpFront page for answers to your questions about why some are wary of relying upon lots of up-front design, or XpIsForBadPlanners for the opposing view. (The discussion doesn't belong on this page.)

CategoryMethodology

EditText of this page (last edited August 10, 2004) or FindPage with title or text search