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

Re: [XP] Re: XP is a philosophy not a religion

Expand Messages
  • Adam Sroka
    ... It depends on how well written the code is. If the code is well written I won t have to read all 1,000 lines to find what I need to know. Possibly not even
    Message 1 of 24 , Oct 31, 2009
      On Sat, Oct 31, 2009 at 2:13 AM, zdnfa <zdnfa@...> wrote:
      >
      >
      >
      > >
      > > Code is a form of explicit knowledge that matters. We need to code
      > > explicitly because machines don't have opinions nor do they appreciate
      > > nuance.
      > >
      > > I'm not sure what code standards have to do with that. Code standards
      > > per se are not knowledge at all, they are just about making code
      > > comprehensible to us non-machines.
      > >
      > > We spend a lot of time changing code. In fact, in Agile we spend more
      > > time changing code than almost anything else. We have to change it
      > > because it is wrong. Then when we make it right it becomes wrong
      > > again. It becomes wrong because it is explicit and real knowledge
      > > isn't.
      > >
      > > Understanding how and why the explicit knowledge in code becomes wrong
      > > is hard. That is why we need lots of tests. Tests break when we try to
      > > change things. That lets us know what we need to do to help the code
      > > to evolve towards what tacit truth is telling us. We can also add more
      > > tests when we learn new things about the stuff we thought we already
      > > knew.
      > >
      > > Documents are just as wrong as code. Documents don't break when we
      > > make them lie. Documents don't let us know how they need to change or
      > > when we get it right. Documents are hard to verify and thus harder to
      > > change.
      > >
      >
      > You are right, But as you just said, we need a self-documenting code in order to comprehend what has been done. This is exactly an explicit knowledge. The question is: is that enough? can code reveal all what we need to know? We all know that a picture is worth 1000 words, don't you think that a reverse engineered code (one that has passed acceptance test) to a class diagram, use case, or swim lane diagram is easier to understand than reading a 1000 lines of code.
      >

      It depends on how well written the code is. If the code is well
      written I won't have to read all 1,000 lines to find what I need to
      know. Possibly not even 100. As a programmer, if the UML diagram is
      easier for me to understand than my code then I have a lot of work to
      do.

      > Moreover, if we rely only on tacit knowledge, what happens if the expert programmer- the one who left his knowledge in term of code only- just leaves the organization?
      >

      I don't really know the answer to that, but from experience I can tell
      you that we aren't much better off if he leaves behind a document.

      > What you are saying right now is code and only code, what i'm saying is code is the most important artifact but models are laso helpful.
      >

      Actually, that's an interesting interpretation of what I said. What I
      meant was code is the only form of explicit knowledge that is
      necessary in software projects (Necessary because of the nature of
      machines.) And, that because code is necessarily explicit we must work
      hard to control it and manage change.

      I did not say that code is the only thing that matters. Conversation
      and collaboration matter. Business value, quality, and usability
      matter. None of these things are explicit enough to be captured in
      documents.
    • Tim Ottinger
      I applaud all attempts to take good software development in any and all new directions, provided that the experimenter is not merely trying to adapt the name
      Message 2 of 24 , Nov 10, 2009
        I applaud all attempts to take good software development in any and all new directions, provided that the experimenter is not merely trying to adapt the name "agile" to their old process. It is far better to "be" than to "seem."

        Try whatever you like, don't let barking dogs distract you, and do be conscientious in your application. Measure, report, etc.

        I have found remote pairing to be very successful, despite the personal belief that it would not work, and could not be made to work. It is not perfect, and is second-best in many ways to being physically present, but has advantages and trade-offs.

        In the same way, try new things (and old things) in your agile adventure. Remember that the goal is learning, and finding ways to learn better. Avoid learning-suppression systems and keep moving.

        As regards docs:

        Mockups are good. After all, "it's always a good time to build an
        example", but once the example is implemented in code or tests, it is
        available to all and the original model is not useful. I believe in creating small docs, but only to later obviate and then delete them.

        Tim Ottinger
        http://agileinaflash.blogspot.com/
        http://agileotter.blogspot.com/
      Your message has been successfully submitted and would be delivered to recipients shortly.