Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When starting a new project, are "proactive" designs useful? I mean, if you create a UML diagram/Activity diagram/Use Case/Class diagram/etc. for anything and everything can think of, then when you think you're done, you start coding. Afterwards, you realize an important feature or method was left out. All your spiffy UML diagrams are nice stacks of worthless paper now.

Is it easier/better to design one class, work on it a bit, refine it, then work on it more?

share|improve this question
    
Have you tried TDD / BDD ? –  Raynos Jul 15 '11 at 5:58
    
Yes, this is what I do because nice diagrams are sometimes a waste of time. A good code or a class diagram is easy and very efficient way for multiple iterations if refactoring. –  UML_GURU Jul 15 '11 at 8:35
    
As a side note, "proactive" is not a word anyone will recognize. Terms that will show up on searches are words like: BDUF, Waterfall, maybe Spiral, there's a ton of dismissive mention of this in the Agile cult, and supporters in large/corporate groups that design to meet a predetermined feature set. –  Patrick Hughes Jul 15 '11 at 18:37
add comment

5 Answers

up vote 8 down vote accepted

Contrary to popular opinion I do not buy into the "Big Design Up Front is bad" movement very much.

This statement is used too often as a lead-in to a project with no design at all. The project is started with no design, and none ever materialises during the development.

I also do not believe that this way of working is what the original claimers (from the Extreme Programming / Agile movements, IIRC) intended. They intended that developers would evolve their design alongside the evolving implementation.

Therefore I believe the process should be:

  1. Create just enough design to be able to get started on the project. Note: I am a firm opponent of "one feature at a time" - I believe you should start with a minimal beginning-to-end skeleton implementation instead (also known as a vertical slice). Otherwise you are not doing iterative development but incremental development, and you are still running the risk of having a "big bang integration" when you finally implement the last feature to complete the loop of your project.
  2. Implement your first design.
  3. Evaluate the design and implementation results. This should include feedback from your customer and end-users whenever possible, to ensure you are building the right thing.
  4. Rework and expand your design.
  5. Implement your reworked and expanded design.
  6. Continue with 3 until you are done.
share|improve this answer
    
What you reference in #1 is called a vertical slice, a coherent but minimal implementation that acts as proof of concept. If you insert "integrate feedback from the people who are paying for the software into your design" at #3.5 you're pretty close to Scrum/Agile like I've used. –  Patrick Hughes Jul 15 '11 at 8:51
    
@Patrick Hughes - thanks for the remarks, I thought feedback was an obvious part of evaluating the resutls, but you are right, it is not! I will add it to my reply. –  Joris Timmermans Jul 15 '11 at 9:02
add comment

I usually do alot of UML and other forms of artifacts planing how to do it, and then sometimes overthink it, and implement something else. That leaves me with a lot of papers (I like painting with pen and paper) and many files on the computer.

My best advice is to create as many artifacts as you want/need and keep them. In the end you will see that Software is living. You will sooner or later refactor parts of your software, maybe parts that are well documented and have a lot of UML. Thats how it is. I have spend some time documenting parts of our company Software we were using. After finishing some diagrams and documentations we refactored the part, leaving all my documents doomed.

At some point in your career or your hobby-life, you will think back to some design from earlier and than you have the documents lying around :)

share|improve this answer
add comment

You definitely do not want the "one-feature-at-time" combined with some twisted form of YAGNI to lead to what often happens:

"Oh, so we need to allow the customer to store 3 addresses, so I'll just add three columns to the customer table."

"Shouldn't we try to maintain a relational model with a seperate address table and a surrogate key in case at some point a customer needs 4 addresses."

"YAGNI, they are really gonna need to put in another feature request for us to allow for 4 customers. You're overengineering for a use case that doesn't exist"

"...FML"

A certain amount of "looking ahead" is always required. If this was not the case, then no one would bother with patterns and best practices. Without a high level functional spec, how are you supposed to prioritize which feature comes next. I am not huge on UML, unless its a rough 1st iteration sketch on my legal pad, but the design phase always must include some sort of functional description of how things should behave. This might be contraversial, but I really do not even think it matters all that much what you even do with the spec once it is written down (update it as you go, put it in a folder no one goes to, delete it, etc.). The main benefit of the design process, and coming up with a loose spec, is that it forces you to write all of your ideas down, and see if they make any sense.

share|improve this answer
    
+1. General Eisenhower was with you about the spec: “I have always found that plans are useless, but planning is indispensable.” –  MarkJ Jul 15 '11 at 16:14
add comment

some "proactive" designs => can be useful

Complete detailed upfront design => not lickly to be useful

share|improve this answer
add comment

What you call "proactive design" is generally called "big design up front" (BDUF) and considered a very bad idea. Vendors of UML tools claim to make it work through MDD, i.e. more or less all your code is directly generated from UML diagrams, or by keeping the model in synch with subsequent changes in code. But this never works perfectly and generally has you run into more problems than it's worth.

Is it easier/better to design one class, work on it a bit, refine it, then work on it more?

One class at a time would not be a good idea either. But one feature at a time, while keeping future features in mind when deciding the high-level design, seems to work pretty well.

UML diagrams (or models in general) have the most value in providing a high-level overview of systems. If they become too detailed, the advantages (visual overview) decline, and producing them takes an unjustifiable amount of time.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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