>>I'm looking forward to the day when most developers consider it completely irresponsible to design that >>long without feedback.

So am I.

So how do you change those people's minds? I'm up against that right now.

I can't say that I've converted any die-hards in this arena, but I have often been able to get people to at least think about it by asking these two questions:

When is the last time that you designed something so well up front that the design didn't change at all during the project?
When is the last time that you designed something so well up front that you felt as good about it at the end of the project as you did at the beginning?

Asked in a friendly way (over a beer is ideal), this question will often get even the cockiest designers talking.

Seeing the alternative helps. A while ago I was pairing with someone who, at first, felt we were "hacking", and then it became very obvious that I was writing and leading him to write very high quality production code, and we talked about design constantly, at a deeper level than he was used to. He was in a very receptive frame of mind, and that helped, but I could see all of the epiphanies happening. I love that. :-)

First, I find a target :) Then, watch his pain. Ask about the problems he is currently facing. Ask for help, and started to write simple tests. Some objections come about writing useless test codes. So, I ask him another question about how to understand that the code works appropriately in an automated manner. Sometimes, we together decide not to use junit or whatever else and start to make calls from a main method. Actually, at that time, without telling him, we implement very simple unit test framework. Afterawhile, completing the simple tests, it appears that we come up with a simple junit :)
In the end, they also understand that we built a unit test framework. It is really great emotion to see them enlightened.

It's hard to find the middle sometimes. It's relatively easy to either go too far or to not go far enough. There is a real need for design prior to getting into the code. I tried doing "bowling kata" for too long, squelching design sense, not thinking ahead, but it only led to trouble. I also know that I can overthink a problem. Either way is not ideal.

What we need is to understand when we understand "enough" and when we don't. That's a little trickier.

I agree. IMHO, upfront design is something everyone should be able to do, and everyone should be able to design on-the-fly. I think that without both those skills we aren't really where we need to be to handle whatever comes -- MichaelFeathers

There's a difference between writing some UML on a white board and doing a 50 or 1000 page document that's signed off by the CTO. I think Michael's talking about something closer to the latter (please correct me if I'm wrong).

Yeah, it's pretty much the latter. Really, I'm talking more about the attitude that it is irresponsible not to go through the entire due diligence before writing any code. It's an old ingrained attitude. Part of it, I suspect, is a remnant from the days when machine time was expensive. Like anything else, it's easy for people to rationalize constraints into virtues. -- MichaelFeathers

The key w/ any advance design is to recognize that sometimes it's right and sometimes it's not. It is important to stay open to directions the code is leading you in spite of what you decided before you started coding.

Well, certainly in that case. No, you don't have to have it all worked out. But it's a good idea to know you're about to do some immediate design. Despite what some documents seem to recommend, diving in with some kind of idea in your head is important. I think that it's also kinda important to have some idea what the design is that you're tampering^H^H^H^H^H^H^H^H^H extending. Without a sense of where you are and a sense of where you're going, I think that even emergent design doesn't have much of a chance.

I think that, structurally, it is more important to know where you are than where you are going. Sure, you need to know where you are going functionally, but there are an incredible number of choices to make regarding structure. Emergent design happens when we pay -at least- as much attention to our current design as we do to our ideas of where the structure could go. MichaelFeathers

Design: An ideal solution, that, at least in theory, solves the problem at hand.
Prototype (spike): A working implementation of the design.

Creating a big design without a working prototype is irresponsible because it might be inimplementable. On the other hand, having several prototypes and no big desing up front can also be irresponsible.

How can we balance both?

Usually people design better what they have already implemented. They know exactly specific details that most people would learn the hard way, with a very expensive cost.

Architecture astronauts usually have never implemented anything and therefore they refuse to write code. They don't know how and they despise programmers, as if programming was a menial work. The fact that those astronauts are the key that makes projects fail is usually not clearly perceived by upper management.

There is a huge system that runs 24x7 uninterrupted for several years: The internet. It does not need UML, but it does have design documents in ASCII called RFC: Request For Comments. So designing is about releasing documents in the open for others to comment. No RFC is allowed unless there is a working prototype for others to see working. That fits the definition of prototype.

I have found that an immediate upfront design usually works well. The type of design where a few hours, even in less than 1 hour, before you start coding you draw your UML pictures just to see where you are and if your ideas are well structured in terms of where you are going. Sure, these designs still fall short sometimes and almost never end up looking exactly the same after some code has been written, but can prevent falling around completely with just coding and no designs, ending up saving you a minimum of 30mins - 1h of coding which is ideal taking the looming deadlines of today's goal-driven businesses into consideration.

<a href="http://shurl.org/vdjGY#viagra">discount viagra</a> [url=http://shurl.org/vdjGY#viagra]discount viagra[/url] <a href="http://shurl.org/lxtDx#viagra">viagra sale</a> [url=http://shurl.org/lxtDx#viagra]viagra sale[/url] <a href="http://shurl.org/hluFj#viagra">buy generic viagra</a> [url=http://shurl.org/hluFj#viagra]buy generic viagra[/url] <a href="http://shurl.org/IDNKq#viagra">cheap viagra</a> [url=http://shurl.org/IDNKq#viagra]cheap viagra[/url]

<a href="http://benimblog.com/cayman/#cialis">generic cialis</a> [url=http://benimblog.com/cayman/#cialis]generic cialis[/url] <a href="http://benimblog.com/carrera/#viagra">generic viagra</a> [url=http://benimblog.com/carrera/#viagra]generic viagra[/url] <a href="http://benimblog.com/boxster/#viagra">buy generic viagra</a> [url=http://benimblog.com/boxster/#viagra]buy generic viagra[/url] <a href="http://benimblog.com/cayenne/#levitra">generic levitra</a> [url=http://benimblog.com/cayenne/#levitra]generic levitra[/url]