[The Neoracle]

sbromley, on 25 June 2010 - 09:03 AM, said:

So then from an Agile standpoint is the design process that my team has implemented sound? Same questions from just a software in general standpoint?

Also for people that started recently or people that have been using agile for awhile, do the developers actually use TDD and pair programming? From The Neoracle's list, my team implements all those things except TDD and pair programming. I'm wondering how long, if ever, does it take for those things to catch on with developers.

The question of "how do we know if we're writing good software" is an age old question. Does, over say months and months, your team's velocity decrease because it's becoming harder and harder to change your software? This is kind of tricky because it's easy to game velocity over the short term and because your estimation tends to change from quarter to quarter. This is usually referred to as "Technical Debt". Also, Michael Feathers recent spoke at RailsConf about this: http://www.mefeedia.com/watch/31587622


Now, do developers actually use TDD and Pairing?
TDD: I'm from the ruby world, and whether you should TDD isn't even a discussion anymore. There are probably a lot of Rubyist that don't do TDD, but it's completely accepted that TDD is the way you _should_ be writing code. I don't write a single line of Ruby or Javascript without writing tests first. In fact, most of my Ruby is written by first writing Cucumber full-stack acceptance tests and then unit testing the individual pieces. Most people, when they first learn of TDD think it's a QA thing. That testing increases quality. That is a nice side effect, but real TDD/BDD is a design tool. Tested code is flexible, modular, "clean" (in the Uncle Bob sense) code. Code that is TDD's tends to be *much* more simple and it's almost completely impossible to truely refactor code without tests in place. I also write code twice as fast when TDDing. My favorite parlor trick, when working with someone new, or new to TDDing or new to Ruby or whatever is to develop a feature without ever opening a browser and manually testing what I'm doing. I have enough confidence that I can write a test and make it pass and refactor my way to working software, and once I have all tests passing and the code looking like i'd like, I'll open up the browser and let them use it, and it _just works_.

Pairing: The previous 3 companies I've worked at have all done pair programming and there are a number of high profile consulting companies that do only pairing (Thoughtworks being the largest I know of). Pairing takes some getting used to, and you have to have at least 2 motivated individuals to get it started. You also need a setup with two keyboards and mice and a desk big enough to sit two people at. However, there isn't a more enjoyable way to write code than Pairing and usually it really is much more productive. All that time you spend looking up documentation or checking your email, or whatever (which I find can be as much as 1/2 your day), is usually reduced to just a few minutes because your pair probably knows the stuff you don't and your pair isn't going to handle you sitting there reading your tweet stream all day.

[The Neoracle]

sujayg, on 25 June 2010 - 10:48 AM, said:

A very interesting thread . I recently attended a SCRUM meetup and I had a simple question . Maybe I shall get my answer here

As regards design patterns, I can say, it is not neccessary to follow design patterns everywhere, as it might be an overkill - so sometimes, following a good design is better than following a design pattern

The question is - I am following a process which delivers quality output to my customer in time. As a team , we work on peer review, NUnit testing, automated testing , internal meets to know where do we stand , etc . ... but I am not following any methodology as such .

In this scenario , what is the benefit of moving to SCRUM .

First I'll point you to this:
http://xprogramming....es/jatbaseball/

Then I'll say, that if what you do works for you, then I wouldn't change it.

However, I will point out that all the things in XP and scrum are there for a reason (btw, XP is a set of development practices, Scrum is a project management system that can be applied to all projects, not just software projects, they can co-exist but you can do XP without scrum). They are symbiotic and are there because each one helps another one. If you don't do TDD then you don't need a CI server. If you do TDD then you need a CI server so everyone knows the status of your build. Etc. etc. I tend to find that teams that adopt a methodology and practice it and get good at it, and *then* start removing pieces they find unnecessary for their situation are much more successful than teams that ignore practices because they come up with some excuse as to why it shouldn't apply to them. In fact, when talking with teams, my internal barometer of their agile maturity level is how many excuses they give for why they don't do some piece of XP or whatever. The least mature teams will give 3, 4 maybe 5 reasons why they can't pair, but mature teams that don't pair usually have 1 really good reason why it wasn't worth it to them.