What modelling technique do you use for your continuous design? [closed]

Question

Together with my teammates, I'm trying to self-learn XP and apply its principles. We're successfully working in TDD and happily refactoring our code and design. However we're having problems with the overall view of the design of the project.

Lately we were wondering what would be the "good" practices for an effective continuous design of the code. We're not strictly seeking the right model, like CRC cards, communication diagrams, etc., instead we're looking for a technique to constantly collaborate on the high level view of the system (not too high though).

I'll try to explain myself better: I'm actually interested in the way CRC cards are used to brainstorm a model and I would mix them with some very rough UML diagrams (that we already use). However, what we're looking for are some principles for deciding when, how and how much to model during our iterations.

Have you any suggestion on this matter? For example, when your teammates and you know you need a design session and how your meetings work?

Answer 1

We call a design session whenever any of us feels uncertain about how to implement a new feature / refactoring. Or even if we feel we clearly have a (rough) idea, but the problem is complex enough so that we don't fully oversee the whole of it.

In the first case, it is obvious that we benefit from discussing the problem together and getting thoughts, suggestions and criticism from others. In the second case it is still true that the more eyes there are to check the rough design, the better. But even if the design turns out to be "perfect" (which practically never happens in real life), it is still beneficial to share the common understanding about the specific problem and its solution within the team. This helps keeping the architectural vision consistent across the whole team.

We use rough UML sketches, but no CRC cards btw.

Answer 2

The way I see it, building a complex program is like building a house. How do you build a house? Well you need to draw the blueprints, create the wooden frame, install the piping, install electricity, roof the frame, lay tiling for the floors, etc. etc. Tackling a complex program without properly understanding everything that it will do is like building a house without knowing how many rooms to construct. You might end up building a wall which you'll end up having to tear down because you need to add another room. Worse, maybe you'd have to completely tear out the floor to direct piping to the new room because it's going to be a bathroom.

Unfortunately, not knowing how many rooms you're going to construct is fairly normal in program design, and sometimes that can't be helped. However, a good approach to designing a complex program with this idea in mind is to build a skeleton that limits you in all the ways you'd expect little change (create an interface to access the database for instance, since you know you're going to have to access some database at some point in your program). Spend a good bit of effort into the skeleton, and future alterations will be easy, since you foresaw the possibility of that change. Rather than knock down walls later getting back to my metaphor, you never build a wall because there was the possibility of extending that room.

All things being said, it's impossible to anticipate every change and you can't very well build a program without committing to some changes, so it just takes experience to know how best to approach creating a program design.

Answer 3

You are writing a code for a particular system, which having some flow to run. It's crucial to understand why we are making design, for ourself, definitely not. The design is not made for ourself, it's for the user, who is going to use the system, program the system, maintain the system. If we want to understand the system in the users perspective, its design will be definitely different than a design made for the programmer of the system. Choose the tool accordingly which fulfills the requirement of the particular User.

Answer 4

I use a mix of methods:

1. Design meeting. Pro's, you set an agenda and hopefully get coherent agreement on design direction. Con's, expensive in terms of time and people.
2. Pair programming. Pro's, shares knowledge, two heads focused on one problem. Con's, wasteful for boilerplate code and the like, can be hard to justify to management.
3. Prototyping. I prototype extensively, I pretty much write twice, deploy once, it lets you figure out where the problem points are without committing too it.
4. Refactoring. Ties into prototyping really, but design your software along good principles (SOLID for example) and refactoring becomes easier allowing you to ease out the problems.