Articles Forum - To Plan or Not to Plan

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Articles Forum
To Plan or Not to Plan

19 replies on 2 pages. Most recent reply: Feb 15, 2004 1:16 PM by todd hoff

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 19 replies on 2 pages [ 1 2 | » ]

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

To Plan or Not to Plan

Posted: Jan 11, 2004 9:00 PM

Ward Cunningham talks with Bill Venners about using the programming language, rather than the whiteboard, to design and communicate ideas.

Read this Artima.com interview with Ward Cunningham:

http://www.artima/com/intv/extreme.html

What do you think of Ward's comments?

rubyfan

Posts: 22
Nickname: rubyfan
Registered: Jan, 2004

Re: To Plan or Not to Plan

Posted: Jan 11, 2004 10:49 PM

Cunningham: I love computer graphics, but every system I've seen to try to turn programming into pictures has lost that syntactic element. There's something about syntax that makes it very precise for reading.

Agreed, I never could understand the hype about UML. Maybe it's because I came from a hardware design background where we made the transition from using graphical schematics to textual hardware design languages back in the early to mid 90's. The whole move to UML seems backwards. A textual description is a lot easier to deal with than graphics; It's very difficult to grep for something in UML for example and how do you parse a picture?. That being the case, it seems more sensible just to use your programming langauge.

Bill Venners: If you don't spend that other time designing?

The implication of this question is that programming and designing are two distinct activities (that when you're doing one you can't be doing the other). Though Ward didn't say so explicitly, I get the impression that he's saying that designing and programming don't need to be considered seperate activities. The more holistic approach is to consider them (and do them) together.

I once worked in a corporate environment where the two activities (programming and design) were totally divorced from each other. The boss said that she should be able to write up a detailed spec for the design and then hand it off to low-level code monkies who would implement it exactly to the spec. She required a 50 page document prior to writing a line of code and prototyping was _not_ allowed. I found that as a result we were producing brittle code that was not easily adaptable as the situation changed. We were always behind schedule as we had to take so much time just preparing the design document up front. And when the design document was completed it was considered to be written in stone; it would take an act of congress to get it amended even if you discovered that the document was seriously flawed in the course of doing the implementation. As this system became more and more entrenched I found that I just couldn't develop software in that kind of environment. I didn't know anything about XP or the Agile development movement then, but it seems that I was already thinking along those lines since I liked to prototype and do design and development together in smaller chunks. Unfortunately, at the time, I thought that it was somehow a problem with me and that I must somehow be doing it 'wrong'. Now I know better.
Thanks Ward, Kent and others in the XP/Agile development camp; you're setting us free.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: To Plan or Not to Plan

Posted: Jan 12, 2004 9:33 AM

Bill Venners: plan for the future, to design for reuse
Would that be the future six-months, or the future this week? Planning for something just-in-case it might happen, is surely different than planning for something that is part of this iteration but not part of todays work.

We understand that planning with a six-month time-horizon has much more risk than planning with a one-week time-horizon.

Bill Venners: At the beginning, you don't understand the problem enough to know what to design. You discover a lot about the problem space by implementing the code. Coding is almost like exploring the space.
Language is so fluid - just 30 years ago, "coding" was taken to mean an almost mechanical translation of design to something a computer could deal with.

"The creative activity of programming - to be distinguished from coding... It is here considered as a sequence of design decisions concerning the decomposition of tasks into subtasks and of data into data structures."

Program Development by Stepwise Refinement
http://www.acm.org/classics/dec95/

Bill Venners: Grandma Moses
And we know that many great artists use multiple design studies, and then sketch in perspective grids, position and reposition figures, before they start painting. Was Grandma Moses painting the same painting over and over again?

Time you spend thinking about tomorrow is time you're not spending thinking about what to do today.
True, but not necessarily wasteful.
If tomorrow really is Tomorrow (rather than some distant future), not looking-ahead for possible interactions could be considered to be working blind.

Nobody says, "Make a master plan for the page. Figure out what paragraphs are going to do.
There's a huge difference between personal letters (which mostly exist as a form of self expression) and other forms of purposeful writing.

Edward Guiness

Posts: 2
Nickname: edwardg
Registered: Jan, 2004

Re: To Plan or Not to Plan

Posted: Jan 12, 2004 1:03 PM

She required a 50 page document prior to writing a line of code and prototyping was _not_ allowed. I found that as a result we were producing brittle code that was not easily adaptable as the situation changed.

My sympathies. I have also been in this situation, forced to work hard on design documents without proper and continuous feedback.

What I ended up doing was cheating.

I would spend the requisite time "writing the document" when what I was really doing was working out firstly who I had to please, and then pressing them (gently) for what really mattered to them. I would end up with a good descriptions of important parts of the system, but with nowhere near enough detail to qualify as a classic design document. I would hand off to the programmers with a warm invitation to chat about anything they might find in the design that was too vague to implement, and then spend lots of time making ad hoc design decisions, but always in keeping with what was important.

Mostly, this worked well. The delivered systems would always contain the most important parts as promised.

Occasionally something would get missed, or some technical detail would make life a little harder, but overall, especially with the benefit of hindsight, I'm glad I cheated.

Peter Hickman

Posts: 41
Nickname: peterhi
Registered: Mar, 2003

Re: To Plan or Not to Plan

Posted: Jan 12, 2004 3:27 PM

> I once worked in a corporate environment where the two
> activities (programming and design) were totally divorced
> from each other.

Having been a code monkey at one such place where the separation of design from coding meant that us code monkeys never actually got to see the design. It was assumed that we would just churn out code and like some sort of tool shop and it would all fit together. Without knowing the design we could not reuse code or suggest alternate designs. In effect each program (there were 600+ of them in the product) was a product in itself. As the simplest function now became a full blown program the maintenence cost just sky rocketed and testing was cursory as we didn't actually know how the whole thing hung together.

When a bug surfaced it was fixed where it was noticed because, to tell the truth, tracking it back to it's source was simply too hard.

The whole thing had been allowed to get bigger than it needed to be because the people doing the design equated more paperwork with better design.

When we got really stuck we asked the salesmen what the code we were working on was supposed to do.

I have never, in 20 years of programming, seen the introduction of 'new procedures' (aka 'more paperwork') actually improve anything.

Cut to the chase, write some code and be prepared to rewrite it.

rubyfan

Posts: 22
Nickname: rubyfan
Registered: Jan, 2004

Re: To Plan or Not to Plan

Posted: Jan 12, 2004 3:41 PM

What I ended up doing was cheating.

So did I.

In the case I was thinking about, I was doing the design
document and then I was supposed to start coding to it
after the document was approved. Of course I started
coding early, but I got in trouble for it. I left the
company soon thereafter as things seemed to be getting
more and more ridiculous there.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: To Plan or Not to Plan

Posted: Jan 12, 2004 10:27 PM

"If we write 10 programs a day instead of one program every 10 days, we just get that much more experience."

This is a curious statement. Are we basically talking about processes that relate to problems of such simplicity that programs can be turned out at the rate of 10 per day?

Maybe I'm slow (OK I admit I am, compared to some) but I can't imagine turning out a commercially useful program in 48 minutes (8 hours/10) and repeating that 10 times in a day.

Vince.

Ged Byrne

Posts: 22
Nickname: gedb
Registered: Nov, 2003

Could XP have created Smalltalk?

Posted: Jan 14, 2004 4:58 AM

As reflected in the interview, extreme programmers like the principle of 'You aren't gonna need it'.

I note that the originators of XP are also use Smalltalk.

Do you think that Extreme Programmers sometimes fail to see the limitations of there methodology. For example, I do not see how the XP approach could have ever produced Smalltalk.

In smalltalk everything is an object, including basic types such as integer. This strikes me as a big vision thing. If XPers were developing Smalltalk (in a pair, of course) I would imagine the conversation would go something like:

"We need to add together 2 numbers"
"OK, lets write an Integer object, I'll start on the tests."
"Why?"
"We always test first."
"No, I mean why develop an Integer Object. Integers are bytes, not objects."
"Yes, but shouldn't everything be an object."
"Even integers?"
"Yes."
"Are we going to need it?"
"It would be nice."
"Can we add these two numbers together without an integer object?"
"Well, yes."
"Then you aren't going to need it."

The Smalltalk environment strikes me as the product of some very high level thinking, the type of up front design that XP dismisses as unnecessary.

I would say that this type of forward thinking design created Smalltalk and OO as we now know it. The flexibility of that type of environment is what made the agile style of development possible. The only reason that XPers are able to take there approach is the support of the framework they work in.

They were able to use this support because it already existed, it was built into Smalltalk long before any of them ever even realised they might need it.

Certainly, there are problems when this type of up front design causes problems when applied to an unsuitable task.

However, I'm sure we will also find situations where trying to apply the XP methods, when up front design is needed, will also cause problems.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003