Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

closed as too broad by gnat, Dan Pichelman, MichaelT, Martijn Pieters, amon Feb 22 '14 at 15:34

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 2 down vote accepted

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.

share|improve this answer
I have a lot of questions, I'm sorry but I'm so curious! :) How often do you usually make a design session? How long does it take you? (do you timebox it?) Do you pin the resulting sketches somewhere around the team workplace? – Marco Ciambrone Feb 3 '11 at 14:42
@d3prok, it varies. In a previous project where we were building an app from scratch, we had design sessions weekly on average, and they usually lasted from 30 minutes to 1,5 hours (if it took longer, we usually broke it up into multiple sessions). We used a whiteboard, and the sketches stayed there for a couple of weeks. One of the project goals was to have good documentation, so many of the sketches (or rather what evolved from them during implementation) later got incorporated into our design docs. – Péter Török Feb 3 '11 at 15:07
@d3prok, currently I am working on a legacy project, so design sessions are needed much less frequently. Often we do design reviews instead, after something has been implemented/refactored by someone. – Péter Török Feb 3 '11 at 15:10
éter, thanks a lot for these experiences sharing! Thinking deeply over it, I will arrange with the team explicit timeboxed design sessions during the iteration planning (through customer tests driven explorations) and also right after each daily standup (at least at the beginning, to make the team accustomed to daily design). About the models...I'll wait for the team to take a decision :) – Marco Ciambrone Feb 3 '11 at 16:18

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.

share|improve this answer
No. Designing a complex program is more like designing a house. Building is a very misleading analogy. I have never seen [ Big Design Up Front ]( working in a nontrivial software project. – Péter Török Feb 3 '11 at 10:04
I am not interested in flame wars nor trying to insult each other personally; I am here to learn and to help others learn. I believe the tone of my comment was factual and not offensive, but please give me concrete feedback if you feel otherwise. And if you have convincing facts/arguments to prove your point, I am most happy to listen. – Péter Török Feb 3 '11 at 15:00

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.

share|improve this answer

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.
share|improve this answer
2-3-4 we already apply them all and we're very happy with these practices. My question is exactly about your first item: how do you "optimize" your design sessions/meetings? – Marco Ciambrone Feb 3 '11 at 14:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.