Vitaliy wrote:
> Rolf wrote:
>   
>> The best analogy I can think of is 'Agile Programming'... sure, it
>> works, and it works well for some people, but it is not for everyone,
>> and you can get programs that work just as well using other more
>> traditional ways. Still, it has advantages and disadvantages.
>>     
>
> I'm curious -- what is your experience with Agile? Can you address the 
> points you made, in more detail? Especially the "disadvantages" part?
>
> Vitaliy 
>
>   
Sure, I have experience with 'diluted' Agile development. I work in the 
financial software industry (... while Alan B. Pearce was sending code 
to the moon, I was feeding code to the financial crisis... ) and we 
often get threatened with 'Agile Development'. In fact, in many ways we 
do some form of Agile development, but it is more a cherry-picked 
version where the company culture has developed in such a way that 
certain practices are compatible with the Agile concept, but it is not 
in any way a formal 'Agile' strategy.

I am solely responsible for certain functionality, and for other aspects 
I work in a team as we together develop and maintain a single complex 
middleware application. On a company level we deliver a complete suite 
of financial risk management software components that interract/live 
together. Further, I get the 'client side' gig when there are 'serious' 
issues on a client site (related to the middleware). It's the sort of 
role where I focus on one thing for a few months and it is littered with 
smaller diversions in to the other responsibilities. Our shop is small 
enough to be able to get deep in to niche areas of the code, yet big 
enough that you have to be able to play along with other departments, 
teams, etc.

Further, the company I work for likes to believe they have the best 
programmers (and I like to agree ;-). We are given a lot of freedom to 
do things 'our way', but the payback is that we have to be flexible, 
multi-skilled, and be willing to re-prioritize things on a management 
whim. I am one of many people in the company who have specialist/niche 
technical and business knowledge, and a broader overlapping system 
knowledge.

When we investigated agile programming we found that it was likely not 
going to fit with our 'culture' because it would actually reduce 
flexibility as we have to regularly switch from development to support 
roles, interspersed with customer interaction and other diversions.

On the other hand, we have a couple of 'Agile' teams that were put 
together to fulfill specific client functionality where there was no 
existing support for that in the current business solutions. These Agile 
teams were assembled and then sequestered from the rest of us so as not 
to be distracted (actually, a couple of them play opera music to keep 
the pressure down, and we kicked them out because we don't like opera... 
;-). Still the one team is still going after 2 years, hardly 'Agile'. 
And worse, the product they developed has won all sorts of awards, and 
is well regarded in the financial industry, unfortunately it is a bugger 
to integrate with the rest of the system. It will probably be 
stand-alone for a while.

In the end I guess you could say the company has a split  personality. 
Development is scheduled from a business-functionality perspective (e.g. 
we need to build a Credit Risk Assessment strategy to calculate Risk 
Metrics on 'Toxic Mortgage Backed Assets'). The Finance Guru's will 
build models of what calculations need to happen (about 30% of our 
company has a phd, and many have 2 - not bad for 'programmers'), and the 
process will be broken down in to what data needs to be available, etc. 
 From that point on a project manager will be assigned the 
responsibility of ensuring the software can produce the correct metrics, 
and will then start the battle of getting dozens of teams to schedule 
time to actually ensure that the databases, middleware, reporting 
frontends, calculation engines, etc. can actually process the data 
coherently.

Agile development would put together a smallish team to work on the 
whole thing from beginning to end with mini milestones, etc. This would 
not work for us because we often need to get many dozens of people 
co-ordinated to get the functionality available in many components that 
need to be backward compatible for hundreds of other Risk-Management 
processes.

Basically the scale of development, testing, integration, and regression 
management preclude any one (small) team of people from having the time 
to learn what they need to know to get the job done.

While I am sure that I am replaceable (the whole hit by a bus thing), I 
also know that in the scheme of things, I have taken years to get to the 
point where I know the financial models, the computing models, the data 
models, and the development models well enough in our company to be able 
to produce top-notch and cost effective software. While there are people 
in the company that could replace me (and I them), a 'fresh' Agile team 
would take years to gain the collective experience of a bunch of people 
to get the task done, and not also run in to all sorts of compatibility, 
regulatory and other issues.

An agile team will fail if it is required to disintegrate routinely to 
work on unrelated maintenance tasks. That's basically why it would not 
(does not) fly really well in the areas i work.

Still, there are times when we need to build (small) new pograms that do 
whizz-bang things, and we get to do the especially fun stuff of rapid 
prototype development, and then it is close to 'Agile'.

For the record, we got a new 'chief' recently up top at work, and his 
philosophy is that maintenance is not much fun, we should all be doing 
agile type development, and we should outsource the maintenance to 
Estonia. Personally I think it would be a mistake because maintenance 
should be the responsibility of the developer if only to ensure that 
they develop maintainable code ... ;-).

Rolf
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist