Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Re: Great video on Craftmanship and ethics by Robert Martin

Expand Messages
  • Tim Ottinger
    ... Do you run a cpu or network monitor? Is there a system tray icon that tells you you have mail? Chat online/offline? Weather applet? Time and date in the
    Message 1 of 97 , Feb 27, 2009
      > > For that matter, couldn't you say that pairing is "multitasking" and
      > > "distracting"? Or working in a team room? Or having to write tests
      > > instead of only code? Focusing our attention for short periods is a
      > > good thing, and tools that do that are aids rather than distractions.
      >
      >
      > I don't find those things distracting. Something blinking at me with
      > every keystroke would be overkill, IMO.

      Do you run a cpu or network monitor? Is there a system tray icon that
      tells you you have mail? Chat online/offline? Weather applet? Time and
      date in the system tray? Do you have an indicator to tell you whether
      your buffer is saved or not? Insert/Overtype mode indicator? Capslock
      buttons? Disk activity light?

      But let's get all down to cases here. Say you're green. Your light
      went green and you know it. Now you type a letter. Because the word
      isn't complete, you're yellow. As you type, because the sentence is
      not complete, you're still yellow. Eventually you have something
      that can compile and you go red. Oh, red. Time to switch over to the
      production code. You start typing and it's yellow. Now "yellow" just
      means "not done yet" to you. That's a good definition of a yellow bar
      anyway. When you finish your thought you hopefully turn green again.
      You start refactoring. There's a rename refactoring (which stays
      green), extract method (still green), extract interface (still green),
      and move method (still green).

      So what's the problem again? That sounds almost like utopia to me.
      Instead of blinking, it is moving green->yellow->red->green along
      with the state of the app.

      Tim Ottinger
      http://agileinaflash.blogspot.com/
      http://agileotter.blogspot.com/
    • tony_t_tubbs
      ... questions. ... Thanks for the clarification. Honestly, I did not hear this in the talk at all, but am glad to hear this now. With books and forums like
      Message 97 of 97 , Mar 3, 2009
        --- In extremeprogramming@yahoogroups.com, John Roth <JohnRoth1@...>
        wrote:
        >
        >
        > tony_t_tubbs said:
        >
        > > I enjoy Uncle Bob's writings and lectures, and am coming from this
        > > with the assumption I should listen to him. However, I have
        questions.
        >
        > > He talked about writing a login page, and putting all the code in the
        > > GUI to start, then pulling out the business layer, then from there
        > > pulling out the DB layer. Doing what he called a spike or thin layer
        > > of functionality top-to-bottom. In theory I get it, it makes sense,
        > > but in practice building testable GUIs is hard, that's why we have
        > > patterns like Presenter First or Presentation Model. If you are not
        > > starting with such a pattern that enables testing, how are you writing
        > > tests? How are you mixing whatever those tests are with writing code
        > > all in the 30 sec bits?
        >
        > You aren't. In XP, the term "spike" means a piece of code you write,
        > possibly without tests, to explore something. It's intended to be thrown
        > away, and that's --almost-- what he did by pulling the data base and
        > then the business logic out of the UI code. When he pulled that logic
        > out is when he wrote the tests for the persistance and domain layers.
        >
        > What's left is the very skeletal UI required to run the screen. That's
        > very, very difficult to write tests for, which is why we try to make it
        > as small as possible. All the testing that's needed is a little stuff to
        > make sure the controls are connected. That can use an external test
        > harness; in fact, it can be left for manual testing in a lot of cases.
        >
        > Everything else is in a lower layer, with a full suite of tests.
        >
        > John Roth
        >

        Thanks for the clarification. Honestly, I did not hear this in the
        talk at all, but am glad to hear this now. With books and forums like
        this being my main partners and coaches, some things come off to me as
        really good sounding theory but no way I can see it working in
        practice. (Such as my misunderstanding here) I may be reading more
        into things than is really said, but I just naturally and honestly
        tend to take things very literal. Then I spend half a day reading and
        rereading and Googling trying to figure out how I write everything
        into the UI code behinds and do TDD at the same time. There's not
        enough Mountain Dew to keep me sane!

        Thanks again,
        TT
      Your message has been successfully submitted and would be delivered to recipients shortly.