Agile programming (was Re: [P|C] Banksel)
Rolf email (remove spam text)
> 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?
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,
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
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
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
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 ... ;-).
In reply to: <02440FAC51E64566A234870B37489076@ws11>
See also: www.piclist.com/techref/microchip/devprogs.htm?key=programming
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the