Are "Proactive" designs on new projects useful?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

some "proactive" designs => can be useful

Complete detailed upfront design => not lickly to be useful

Answer 4

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.

Answer 5

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 :)