The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Just in Time Design == Improvisation

I was reading the Toyota thread in the other forum and it got me to thinking about how "Just in Time Design == Improvisation". Parsimonious Design is also related to YAGNI.

I think there's different kinds of designers though and many can't handle this sort of thing. Some people want to plan things out in advance. These are the BDUF people and they represent most of the industry, do you think?

I see it when I travel. I never make vacation plans. I just pick a starting country, then move as whims strike me. If I need to enter a country I don't have a visa for, I just improvise (aka bullshit) my way in. If I run out of money, I find some sort of cash only blackmarket job that I can do in a few days. Whatever it takes. It sounds like this is part of the design ethic at Toyota. But if it's not, that's Ok, it's the design ethic I favor. It's where cool ideas come from. Winging it. Making it up as you go along. This is more efficient in the long run since you don't spend a lot of time doing a complete process for some stuff that's not going to work or you don't really need.
Meghraj Reddy
Sunday, April 22, 2007
I disagree... not having *any* plan in advance can get you into trouble.  You won't always see the obvious/common problems in advance and you're likely to run into things that simply can't be dealt with given the time, money, etc.

Oddly enough, I've always used a similar analogy to argue in favor of a more agile approach.  If you were going on a relatively long road trip (think 8+ hours of driving), you're going to pass through some areas you're familiar with, some you may have never been, but you generally know your final destination.  Construction, traffic, etc might change the route you take, when you stop for breaks, and the overall time/effort it takes, but your plan needs to have some flexibility in it to handle and resolve these things or it just doesn't work out for anyone involved.
KC Send private email
Sunday, April 22, 2007
Toyota doesn't advocate NO design. Instead, what it say is this:

Delay decisions until the last RESPONSIBLE moment.

The word "responsible" is key there, obviously.

Why did Toyota find they have to do this? IIRC, the development time for a new car design is on the order of 2-5 years, depending on which company you look at. In our wonderful world of technological advances, that's a helluva long time. You're almost certainly going to have to change your design to accomodate:

1. New technology
2. New legislation
3. New market demands

If you burn decisions into your design early, it will be messier and more expensive to change later. Sure, it's difficult to create a design that postpones decisions, but the result is that Toyota can turn a design into a car on the showroom in about 2 years while GM and Ford can take twice as long.

Btw, I don't really see YAGNI as being related to this. YAGNI is simply the focus on simplicity of design, which has obvious benefits in the manufacturing world (and in ours). I suppose you could still end up with an overcomplicated design while still postponing decisions until the last responsible moment.

I'm also not sure that Toyota would call what they do "improvisation".
Bruce Rennie
Monday, April 23, 2007
2cents.. I highly doubt the Japanese would "wing" it considering their cultural emphasis on consensus.  I think what happens is that they wait until the last moment, figuring this will give time to build that consensus.  I could be completely wrong about this, but the style of traveling and "whatever it takes" sounds very American.
none Send private email
Monday, April 23, 2007
"Delaying a decision" and "not making a plan" are different things. Let's put this in a car context, and I hope it will be obvious how it translates to a software context.

Let's say your new car might have a 4cyl or 6 cyl engine. At some point you need to decide which (or say that it can have either, which is yet another choice).

"Delaying a decision" means that you do the early design work on the car allowing for the possibility that it could have a 4cyl or a 6cyl engine. "Not making a plan" means that the car body designers assume that the car will have a 4cyl engine and do their designs on that basis.

It's obvious I hope that the first of these allows for flexibility; the second is going to cause trouble when marketing tells you it won't sell unless it has a 6cyl engine. I hope it's also obvious that the first option is going to make more work for the body designers.

'Agile' software designs hould be an example f the first case, but if done badly it can be an example of the second. That costs even more time and money as a part of the code which you had thought was finished turns out to need rewriting to cope with some feature that hadn't been considered properly.
DJ Clayworth
Monday, April 23, 2007
Just to be clear, the first option is more work for the body designers compared with making the decision early. If the 'not making a plan' route is followed that can mean even more work if they have to go back and redo their work with a different engine.
DJ Clayworth
Monday, April 23, 2007
> I see it when I travel. I never make vacation plans.

That's fine if nobody else cares when, where, how, or whether you arrive! But it doesn't necessarily scale when there's a team or several teams involved, does it?
Christopher Wells Send private email
Monday, April 23, 2007
Monday, April 23, 2007
A related concept is that of the critical path.

In a nutshell, you make a list of all your activities and determine which ones can "float" and which ones must be completed in sequence.

(Note: it does not mean these activities aren't important, just that there is a lot of flexibility as to when they should be done.)

To continue the driving example, leaving your house, stopping for gas and arriving at your destination are all critical path activities; you must do those in sequence and you must complete the prior activity before moving on to the next. If you didn't stop for gas, you'll never have enough fuel to reach your destination.

You could however, stop for photographs along the way, stop for restroom breaks, take detours to avoid traffic, find a new radio station to listen to, call your friend on your cell phone, etc etc, at any time along the journey and you don't necessarily need to complete one activity before taking on the next. As an example, you could call a friend and send her a cell phone photo of a landmark as you drive into the gas station.

As implied, Toyota also does this to some extent - it has determined which activities are on the critical path and which ones aren't. When they design a car and presumably plan to have it on the showroom floor in two years, they know they need to make a decision about the body in two months, the engine in six months, etc etc, but they pick out the floor mats and dashboard guages whenever its convenient to do so (typically at the last minute).

In the software world, picking icons and taking screen shots are not critical path tasks compared to writing the save data to file routines.

Slight correction: it's possible to have "major tasks" that have critical paths within them, but as a whole, are otherwise non-critical with respect to the overall project. Writing the user documentation would be one example.
Monday, April 23, 2007
I don't think it is necessarily about critical path. Using my example above, you CAN design a car body without pinning down whether you are using a 4cyl or 6cyl engine. Some things you may have to do extra work on to cover both cases, but that allows you to delay the engine decision until much later. I think that's more what they are talking about.
DJ Clayworth
Monday, April 23, 2007
That's a true point.

I volunteered the critical path description in response to anomalous' introduction of DSM.

But while we're on the subject, I also think all of these buzzwords are just semantics. Useful ones to be sure, especially when you've only got 30 minutes to sell someone on your idea, but it's still spin.

For example, you must select an engine before you select a transmission or vice versa. You cannot select the two independently of each other. That implies that the process of selecting the drivetrain (or powertrain) contains a critical path within itself, but as DJ rightly pointed out, the complete drivetrain itself is not a critical path item - you can intentionally delay the decision considerably by designing for multiple drivetrains and car makers frequently do.

I think simply recognizing that critical path items exist (and dependencies within a DSM), makes it easier to understand how you can "delay decisions until the last responsible moment."
Monday, April 23, 2007
Ok, we're getting a bit off the beaten track here, but you're talking about constraints. All a critical path is is the shortest implementation time for a project, based on it's current constraints.

Theory of Constraints and critical chain planning strive to reduce or eliminate the impact of those constraints. While Toyota may not have called it Theory of Constraints, they were definitely aware of the concepts as can be seen in such features of the TPS as "takt time", which is essentially the same as drum-buffer-rope and kaizen activities, which basically embody the five steps of ToC.
Bruce Rennie
Monday, April 23, 2007
Another one of Toyota's innovations was developing the ability to switch tooling very fast. For example, a press that stamps out doors takes time to switch the dies/molds used to shape metal into doors. Traditionally, car manufacturers would take hours to switch dies, while Toyota redesigned how they do things so that it takes minutes. It took: redesigning the presses, redoing the way work was done, how the dies were stored and a few other things I'm forgetting. As a result, they didn't need to store up hours of inventory of doors to cover for changes, they could almost change them as they needed to drop inventory to very low levels.

Part of why/how they could do this was the lack of a hostile management/worker relationship.
Monday, April 23, 2007
> In the software world, picking icons and taking screen
> shots are not critical path tasks compared to writing
> the save data to file routines.

One shop I'm acquainted with, the sequence is
 - Programmer designs an awesome GUI because he
  felt like it
 - Customer passing through sees it and says
  "That's cool!  How soon can I have it?"
 - Management answers "Six months"
 - Programmers code furiously (no time for design!)
 - Seven months later, code review meeting is called
  for thousands of lines of code.  Six or more people
  say, "I haven't had time to look at it.  You
  tested it, right?"
 - Ship it.
 - Start debugging.
Wes Groleau Send private email
Tuesday, April 24, 2007
Tuesday, April 24, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz