On Friday 05 May 2006 1:33 am, Leslie Viljoen wrote:

> How big is your team? Do you use any XP methodologies, or would you give
> us an idea of what methodologies you do use? How big are the programs
> you have written?

Two people, currently, who are geographically separated.

Regarding code size, it varies.  A lot can be done in a small linecount, when 
one doesn't consider the size of frameworks or libraries being used.

The largest single system is 20kloc.  It's a system for a real estate 
appraisal company to manage their appriasal ordering/assignment/tracking 
process paperlessly (and to be honest, if I wrote it today, I'm sure that LOC 
would be under 10k).

There are a number of systems in the 5-10kloc neighborhood that are used for a 
lot of different data tracking/handling tasks in various companies.  And then 
there are a bunch of small systems, many less than 2kloc (some much less), 
used for very targetted purposes.

As for methodologies, it really boils down to some very basic things.  There 
is no pair programming or anything of that nature.  The basic process tends 
to move from a general idea about what the company wants through to a set of 
business requirements over the course of a lot of talking with the customer.  
Sometimes they have specific requirements already fleshed out, but in 
practice, the process is one that entails a lot of questioning and discovery, 
as the requirements are often, frankly, very poor.  After that, the process 
becomes one of release early, release often, as it is being developed.

Because that questioning and discovery phase is so common and is tied so 
intimately with nebulous requirements, it goes on contantly while the product 
is being developed, and sometimes that means that halfway through the project 
it is discovered that the customer had a requirement in their heads that was 
poorly communicated or simply assumed on their part, but they don't realize 
it concoulsly until they see the project coming together.  It can be a pain, 
but when it happens, it happens, and we just deal with it.

Throughout the development process there is a lot of testing, both from 
automated tests and the human-driven variety.  That makes it easier to shift 
gears midstream when an unexpected requirement rears its head.  It also helps 
ensure that when the system is finally delivered in a completed form to the 
customer, that it fullfills their business requirements, and it makes it 
easier to write documentation for them.

Like I said, there isn't a lot of really sophisticated methodology.  It's all 
pretty basic.  Get the best requirements one can, usually through  alot of 
discussion and questioning.  Stay agile in devopment because requirements 
will mutate.  Keep asking questions.  Don't over-engineer; it tends to 
interfere with the requirement to stay agile, even when it seems like a good 
idea at first.  :)  And test test test.

That's basically it.


Kirk Haines