On Jan 28, 2009, at 10:27 PM, Rolf wrote:

> I am solely responsible for certain functionality, and for other  
> aspects

That is surprising in financial software.  You could add the famous  
"shave off all the rounded numbers into my Swiss bank account"  
function in your code, and no one would audit it?

We can't even do that in "answer the phone line" code in telco --  
hearing that there's ever only ONE engineer in charge of a function in  
financial code, doesn't give me warm fuzzies.

(Yeah, I know they'd catch the above example, but you get the idea.)

> 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

I guess it doesn't manage risk all that well -- or your customers all  
didn't lose 30% last year like everyone else?  Hahahaha...

Well, you did say you were "feeding code to the financial crisis", and  
everything I've heard is that the mortgage stuff was quite heavily  
affected by "computer models".  Not that I don't hold the dolts who  
BELIEVED the models responsible, mind you... but it's interesting stuff.

> 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

That right there says something.  The best rarely think they are.  :-)

> 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.

If they're reprioritizing on a "management whim", the managers aren't  
very good and don't have very good goal-setting skills in the first  
place.  So I wouldn't put too much stock in that "best programmers"  
thing, since they're not very good managers to begin with.

> 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.

One that writes award-winning software, and one that doesn't?  Heh heh.

> 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.

And meanwhile the bank using the software should have just turned the  
idiot with the nose-ring and his girlfriend wearing the "I'm with  
Stupid" T-shirt down for the loan... hah.

> 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.

Isn't your job as you described it -- as an individual -- already a  
"small team" within that bigger whole that gets those big projects  
done?  You do things you say the other's can't, you have your own  
deadlines and goals... things change, you adapt... sounds "Agile" to me!

> 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.

This is why (and I don't like this model, but it's still commonly  
done) many companies break up "Product Engineering", and "Continuation  
Engineering" into different departments that don't co-mingle.

> 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 ... ;-).

How about pushing for code that needs LESS maintenance from the  
start?  Write once, use.  :-)

(Everyone says it's impossible, but we've all seen small projects  
where it somehow worked out and the "thing" hasn't been touched for  
years, and still works.  I'm not a programmer by trade, but it seems  
to me like Agile is all about just scaling that "small win" type  
situation up into the building blocks for a bigger project, isn't it?)

It *is* possible to write almost perfect code, after all...

http://www.fastcompany.com/node/28121/print

:-)

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