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?

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.

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.

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.

> 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.

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.

"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.

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.

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've been wondering about this too.

"Smalltalk's design--and existence--is due to the insight that everything we can describe can be represented by the recursive composition of a single kind of behavioral building block that hides its combination of state and process inside itself and can be dealt with only through the exchange of messages."
http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html


My guess is XP talks about this design insight as Metaphor.

Let's note "I won't kid you - there is no formula for flashes of design insight... TDD can't guarantee that we will have flashes of insight at the right moment. However, confidence giving tests and carefully factored code give us preparation for insight, and preparation for applying that insight when it comes." Test Driven Development.

(Then again here's Dijkstra "I assume the programmer's genius matched to the difficulty of his problem and assume that he has arrived at a suitable subdivision of the task."
'Programming Considered as a Human Activity" EWD117)

Thanks for those great quotes, especially the Smalltalk history.

My two cents:

If the goal is to add two numbers together, XP wouldn't see the need for numbers to be objects. But then, nobody's ever claimed that XP is a language design tool. It's a tool used to build software.

Sure, a language has to be implemented & there XP could be useful - but it wouldn't have a thing to say about the language design. Whether or not everything is an object would be a user story from the customer & not a design decision.

So a programming language is one piece of code that does require up front design.

What other areas also need up front design? Financial software? Point of sale software? What exactly are the boundaries of XP?

> So a programming language is one piece of code that does
> require up front design.
>
> What other areas also need up front design? Financial
> software? Point of sale software? What exactly are the
> boundaries of XP?

I separate the how from the what. Customers, performance requirements, GUI requirements, size requirements are all part of 'what'. 'how' is where XP techniques make the implementation of all these things faster and more effective.

Good system design is still important!

RTFM :) [http://www.amazon.com/exec/obidos/ASIN/0201616416/104-2727119-7004753]

I think those 2 guys would have trouble putting out BASIC regardless of the methodology used.

You can still have vision in XP. Making everything an object would be a requirement. You still have requirements in XP.

You also don't typically have just 2 programmers. You have a team of programmers who split up into multiple pairs. The pairs change from day to day. And you have collective code ownership, so that the next day one of the team members who actually has a clue would see the work these 2 did, talk to the boss, and perhaps the incompetent programmers get re-assigned to janitorial duty.