Article Discussion
To Plan or Not to Plan
Summary: Ward Cunningham talks with Bill Venners about using the programming language, rather than the whiteboard, to design and communicate ideas.
19 posts.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: February 15, 2004 1:16 PM by todd
    Bill
     
    Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM
    To Plan or Not to Plan
    January 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?
    • Isaac
       
      Posts: 51 / Nickname: igouy / Registered: July 10, 2003 7:42 AM
      Re: To Plan or Not to Plan
      January 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.
    • rubyfan
       
      Posts: 8 / Nickname: rubyfan / Registered: January 1, 2004 4:07 PM
      Re: To Plan or Not to Plan
      January 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.
      • Peter
         
        Posts: 5 / Nickname: peterhi / Registered: March 31, 2003 2:46 AM
        Re: To Plan or Not to Plan
        January 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.
      • Edward
         
        Posts: 1 / Nickname: edwardg / Registered: January 12, 2004 7:50 AM
        Re: To Plan or Not to Plan
        January 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.
        • rubyfan
           
          Posts: 8 / Nickname: rubyfan / Registered: January 1, 2004 4:07 PM
          Re: To Plan or Not to Plan
          January 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
       
      Posts: 40 / Nickname: vincent / Registered: November 13, 2002 7:25 AM
      Re: To Plan or Not to Plan
      January 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
       
      Posts: 5 / Nickname: gedb / Registered: November 17, 2003 4:42 AM
      Could XP have created Smalltalk?
      January 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
         
        Posts: 51 / Nickname: igouy / Registered: July 10, 2003 7:42 AM
        Re: Could XP have created Smalltalk?
        January 14, 2004 10:24 AM      
        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)
        • Ged
           
          Posts: 5 / Nickname: gedb / Registered: November 17, 2003 4:42 AM
          Re: Could XP have created Smalltalk?
          January 14, 2004 4:44 PM      
          Thanks for those great quotes, especially the Smalltalk history.
      • Kelly R.
         
        Posts: 2 / Nickname: kdenehy / Registered: December 2, 2003 1:42 AM
        Re: Could XP have created Smalltalk?
        January 17, 2004 7:01 AM      
        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.
        • Ged
           
          Posts: 5 / Nickname: gedb / Registered: November 17, 2003 4:42 AM
          Re: Could XP have created Smalltalk?
          January 19, 2004 5:39 AM      
          Thanks for the replies and patience.

          The new installment goes a long way to answering my question.

          I guess that the extra effort needed to implement Smalltalk purely as recursive objects comes under the heading of 'complexity that is empowering,' like the learning the new branch of mathematics in order to reach a 10 page proof.
      • Charles
         
        Posts: 4 / Nickname: hawscs / Registered: November 26, 2003 2:22 AM
        Re: Could XP have created Smalltalk?
        January 15, 2004 6:48 AM      
        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.
        • Ged
           
          Posts: 5 / Nickname: gedb / Registered: November 17, 2003 4:42 AM
          Re: Could XP have created Smalltalk?
          January 16, 2004 9:52 AM      
          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?
          • Kelly R.
             
            Posts: 2 / Nickname: kdenehy / Registered: December 2, 2003 1:42 AM
            Re: Could XP have created Smalltalk?
            January 17, 2004 6:50 AM      
            RTFM :) [http://www.amazon.com/exec/obidos/ASIN/0201616416/104-2727119-7004753]
          • Gregg
             
            Posts: 28 / Nickname: greggwon / Registered: April 6, 2003 1:36 PM
            Re: Could XP have created Smalltalk?
            January 16, 2004 9:36 PM      
            > 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!
            • Charles
               
              Posts: 4 / Nickname: hawscs / Registered: November 26, 2003 2:22 AM
              Re: Could XP have created Smalltalk?
              January 19, 2004 6:15 AM      
              >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.

              Exactly what I was trying to say, but more clearly! Thank you.
              • Jorge
                 
                Posts: 1 / Nickname: jgiraldo / Registered: September 16, 2003 1:43 PM
                Re: Could XP have created Smalltalk?
                January 23, 2004 8:22 AM      
                I think of a language designer as a special case in which the same person can be both the client and the programmer. He would also have "two hats", and he would not wear them at the same time.

                When the designer is wearing the client's hat, he's thinking globally, ahead of time. He has to have a clear vision of his "business problems", the language he wants to make. Then, he could create stories for implementation.

                Whether or not to make everything an object becomes a "business" decision which should make sense within the overall vision of the new language. It is not a "programmer's" decision, and therefore it doesn't have to be "the simplest thing that works".

                Then, wearing the programmer's hat he could tackle the stories, following XP's rules. He would naturally find out that some of his ideas (as a client) may not be as good as he thought initially. He would have to switch hats to modify his inital vision, but this would be more like a business requirement change, not necessarily a programmer's problem.
    • Roberto
       
      Posts: 1 / Nickname: rocha / Registered: January 28, 2004 9:28 PM
      Re: To Plan or Not to Plan
      January 29, 2004 3:40 AM      
      >To worry about tomorrow is to detract from your work today.

      This is almost like a play with words and logic.
      *Thinking* about tomorrow (or the future) is not the same as *worrying* about tomorrow. One is clearly a negative view of it.

      >Time you spend thinking about tomorrow is time you're not >spending thinking about what to do today.

      Well, that's ok, because you saved time yesterday when you thought about today! :-)
      It's just like instruction pipelining!

      It just sounds like a play with words for not having to plan for the future. People are lazy by their nature, but sometimes it's good to do some work now to avoid making work in the future, but as with all things, having a balanced view is better than being extreme in any direction. (There was a mentioning of Zen, think of Ying/Yang)
      Being extreme is easy, you don't need to balance...

      >There's something about syntax that makes it very precise >for reading. I love photography. A photograph will tell a >story. But words tell a story even better. Words are more >versatile. You can paint a verbal picture that's much >richer than you can photograph.

      Syntax is the grammar, structure, or order of the elements in a language statement.
      What do you mean by saying it makes it very precise for reading?

      Ward, you draw very strange conclusions about words and pictures. How can you say that words are more versatile, for whom are words more versataile?
      Words and pictures will tell different storys for different people, words in particular mean very different things to different people depending on culture etc, but pictures
      on the other hand usually can communicate feelings across cultures.
      It's interesting that you use words to 'paint'! This probably means that you internally create pictures when you read words, and will experience this as telling the story better as you get to chose the pictures!


      >Grandma Moses didn't paint that way.

      Well, first of all we don't know what Grandma Moses paintings looked like!
      And if you draw the parallel to puzzles. Try assembling a
      puzzle without know what the final picture will look like!


      I'm not against XP, I think there are many good things to learn from it. Still I get the feeling it is better applied without the 'extreme' part of it and what it really wants to convey is the 'get dirty and get the work done' idea.
    • todd
       
      Posts: 2 / Nickname: thoff / Registered: January 17, 2004 2:16 AM
      Re: To Plan or Not to Plan
      February 15, 2004 1:16 PM      
      Speed. I can think and scribble at a high level much faster
      than i can code. If i am wrong so what. In XP you are always wrong because the next user story changes whatever your did before, so being wrong isn't a problem.

      Complexity. Let's discuss our clustering system by writing code. Don't think so.

      Appropriate level of abstraction. Code is at one level abstraction. Instead of following simple rules why not use your judgement about what will work best for what you are trying to discuss. Sometimes that is code. Sometimes it is not. The code only is like being shown your DNA instead of an xray of your broken bone.