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

intentional side-effects

Expand Messages
  • ken tyler
    My partner and I are trying to work through some of the things we re finding working for clients and I thought this group my be able to point us in some
    Message 1 of 3 , Jan 2, 2007
    • 0 Attachment
      My partner and I are trying to work through some of the things we're finding
      working for clients and I thought this group my be able to point us in some
      interesting directions. One thing we've noticed is that whenever we work
      with an organization on a project there are clear side effects, both on the
      people working with us and on other work inside the organization that
      overlaps the work of the project. Sometimes I've heard this referred to as
      "un-intended side effects". The "un" seems wrong, since one knows that the
      side effects will happen as a direct consequence of doing the work on the
      project.



      Naturally these side effects are very hard to predict, but they sometimes
      seem to be of great benefit (sometimes more than the original project). Does
      anyone know where we can look to find more on this area ? Has anyone ever
      tried testing whether on not certain side effects occur ? I have to go back
      and re-read Checkland and Weinberg as this seems to be systems theory
      stuff..



      Thanks



      [Non-text portions of this message have been removed]
    • Oleg Puzanov
      Great! Just to add: unit-tests for me is a piece of bravery before refactoring and some kind of intuitive programmist documentation. Cheers, Oleg Puzanov ...
      Message 2 of 3 , Jan 3, 2007
      • 0 Attachment
        Great!

        Just to add: unit-tests for me is a piece of bravery before refactoring and
        some kind of intuitive "programmist" documentation.

        Cheers,

        Oleg Puzanov

        On 1/2/07, Thiago Arrais <thiago.arrais@...> wrote:
        >
        > No, you don't need to read the title again, you are not mistaken. It
        > really is
        > a T instead of a D (or R, depending on where you come from). BTUF is the
        > acronym for Big Testing Up Front. BTUF is basically what happens when
        > people try to write all conceivable tests before starting to code. With
        > the
        > rise of Test-Driven Development this is an obviously ascending waterfall
        > practice.
        >
        > Testing is also designing. When you write the tests before the production
        > code
        > in good TDD style, what you essentially do is design how the code will
        > look from
        > outside. Sometimes it may be hard to resist the temptation to design
        > everything
        > before writing a single line of code, specially for those used to
        > waterfall thinking.
        > For those who can't help doing it, here is some news from yesterday's
        > paper: it
        > doesn't work. Even though everybody minimally informed has already heard
        > it,
        > this message never gets said enough.
        >
        > It doesn't work because designing is infinitely better and easier when we
        > can
        > have fast feedback. Software development can be a high feedback bandwidth
        > activity. Architects need to wait for the construction team to finish
        > the piece and
        > film writers sometimes need to wait years for the shooting to finish, but
        > programmers can just compile their programs. Giving up this feedback on
        > purpose is not the smartest thing to do. Writing all tests for a piece of
        > code
        > before starting the proper code is like drawing rectangles and arrows
        > describing
        > it in full detail before trying to make the whole think work. The
        > over-engineering
        > risk is the same because the code isn't there to scream in agony.
        >
        > The key to avoid BTUF is to write the tests that you can come up with
        > before
        > writing the code to make them green, but make sure _not_ to think too
        > much.
        > You can wait to start writing the code after all tests are in place,
        > but you don't
        > _need_ and neither _want_ to.
        >
        > TDD has shown us that design isn't made only of diagrams. In fact, we are
        > designing all the time we are developing software. TDD is one of many
        > design techniques: one that uses tests. It may be a better tool than
        > arrows and
        > rectangles in some situations. But is still just an approach for
        > design. BTUF is,
        > therefore, just an special case of BDUF where tests are used to determine
        > the
        > design completely before writing a single line of code.
        >
        > Cheers,
        >
        > Thiago Arrais
        > --
        > Mergulhando no Caos - http://thiagoarrais.wordpress.com
        > Pensamentos, idéias e devaneios sobre desenvolvimento de software e
        > tecnologia em geral
        >
        >


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.