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

Re: [XP] Converting the Team

Expand Messages
  • Nicholas Robinson
    David, I was thinking about this lastnight and I came to this conclusion. If you do TDD a few excellent products will be the result. You will begin to write
    Message 1 of 6 , Jul 30 1:18 AM

      I was thinking about this lastnight and I came to this conclusion. If you do TDD a few excellent
      products will be the result. You will begin to write more rebust code with much less defects.
      TDD (and some XP concepts such as YAGNI) gently coerce structures out of your coding, if they are
      required. As you get better at TDD (which will only be through practice), you will find yourself
      moving much faster, producing code at a greater quality than your team mates. Coupled with this
      will be the fact that if done right, you will have much better objects (a side effect Phlip
      alludes too) and inter-relationships/dependancies.

      Anybody worth having respect for on this level will look at your code and its benefits, and begin
      to embrace them. Those that dont, well they arent really worth worrying about.


      --- David Boyer <mangr3n@...> wrote: > I've almost got one of my team members
      convinced of the benefits of TDD
      > vs. traditional development. The rest of the team has zero interest in
      > it. But if I can get one, I might be able to topple the rest. My
      > arguments to him consist of the following main points:
      > 1. The test's created aren't verification of functionality (like QA
      > Testing) they are specification of functionality. They are the design
      > requirements. Therefore they are a fun and precise communication of
      > software intent. This reduces confusion about the results expected by
      > managers, co-workers, customers. This makes it easy to communicate
      > about the software's behavior.
      > 2. The TDD paradigm leads to that holy grail of OO, decoupled code.
      > This is the Nirvana that seems to be impossible to achieve using
      > standard development practices. Decoupled code is testable, but it's
      > also extremely flexible. Optimization is easy, algorithm replacement is
      > easy, all change is easy when it's decoupled.
      > Obviously, we will also have less bugs. But I can't seem to get him
      > over the hump. I think part of it is the resistance to the overwhelming
      > paradigm shift. The other part is convincing him that the traditional
      > mindset has no built in checks and balances against the bad programming
      > practice of spaghetti code or of forcing attention to code smells. We
      > do refactor, but there is no pattern of refactoring as a method to
      > remove TechnicalDebt.
      > I've as yet been unable to completely give myself over to this mindset.
      > It's so radical a departure from the standard model. Part of the
      > issue is institutional(meaning the culture at work), but the rest is
      > just the sheer inertia of making a change of this magnitude.
      > I'd appreciate any suggestions for arguments or examples to bring to the
      > table:
      > Thanks,
      > David B.
      > To Post a message, send it to: extremeprogramming@...
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      > ad-free courtesy of objectmentor.com
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

      Want to chat instantly with your online friends? Get the FREE Yahoo!
      Messenger http://uk.messenger.yahoo.com/
    Your message has been successfully submitted and would be delivered to recipients shortly.