ArticleS. MichaelFeathers.
ChangingNotionsOfDesign [add child]

Changing Notions of Design

Things are changing, but it's slow.

Every once in a while, I run into someone who feels that it is completely irresponsible to program without doing all the "design" first. I'm looking forward to the day when most developers consider it completely irresponsible to design that long without feedback.

 Fri, 12 May 2006 01:24:20, hoping,
>>I'm looking forward to the day when most developers consider it completely irresponsible to design that >>long without feedback.

So am I.
 Fri, 12 May 2006 06:58:51, John Woodard,
So how do you change those people's minds? I'm up against that right now.
 Fri, 12 May 2006 16:40:24, David Chelimsky, re: changing people's minds
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.
 Sat, 13 May 2006 05:56:08, Michael Feathers,
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. :-)
 Sat, 13 May 2006 08:27:52, IsmetKahraman[?], Changing People's Mind
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.
 Tue, 16 May 2006 11:03:04, Tim Ottinger, Finding the middle
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
 Wed, 17 May 2006 14:58:15, David Chelimsky, re: finding the middle
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.
 Wed, 17 May 2006 17:57:07, Tim Ottinger, Ah, well, that's obvious.
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.
 Tue, 23 May 2006 00:37:27, Hans Lautrup, Design and protoypes
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.
 Sat, 2 Sep 2006 12:13:07, Gerrit Grobbelaar, Immediate upfront design
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.