First I take a full-time job, then DonXML does!
http://donxml.com/allthingstechie/archive/2006/03/20/2609.aspx
Don and I are moving in parallel paths. We have both found small consulting companies that are staffed with people that we respect. We both feel, and been given the opportunities, to make a difference in our companies and to help grow the business.
From what I remember, Don does not like to cross the Hudson River, so I will leave him to the NJ Pharma companies while I go after the Financials!
©2006 Marc Adler - All Rights Reserved
Friday, March 24, 2006
Sunday, March 19, 2006
Rules of Engagement
My Expectations from a Client
My first engagement with Finetix has just ended, and it was an eye-opener in certain respects.
I have been thinking about what I would like to include in a retrospective to the client in order to help them manage future projects successfully. Instead of enumerating what I consider to be the positives and negatives of the project, I would like to add some of the aspects to my master “Lessons Learned” list, and also to reiterate some of my long-standing project-management processes.
1) Clearly Define Roles
2) Always Be Engaged
3) Make Sure Everyone Knows Everything
4) Define A Methodology And Stick To It
5) Have The Environment Completely Set Up
6) Have Documentation Ready
7) Engage the Business Analysts and Business Users
8) Do Not Pair-Program Unless Absolutely Necessary
9) Always Have a Roadmap For Refactoring
Clearly Define Roles
If you are bringing in consultants to lead the technical team, then tell your team members and enforce the leadership. If you are expecting your consultants to be short-term body-shoppers who are coding, then tell them this up front. Do not allow incorrect perceptions to pervade the group.
There will always be bruised feelings when you bring consultants on to a project in a leadership role. We consultants completely understand this. Nobody wants their work to be reevaluated and critiqued. If the consultants are being brought in to do rearchitecture, then they must be given the power to lead the effort.
Make it clear as to who holds the trump card.
Always Be Engaged
As a project manager, make sure that you know what all of your team members are doing, and make sure that all team members know what each other is doing. Make sure that the server side and client side teams communicate. Many server-side devs have also done GUI work and vice-versa.
If you have to support a legacy version of your product, then make sure that you are able to delegate that task to certain members of the team. Have a plan to get these “legacy developers” involved with the new development. The legacy devs are subject matter experts who are important to the whole team.
Make Sure Everyone Knows Everything
As mentioned above, do not isolate the groups. Involve the Business Analysts and Business Users where appropriate. Unless there are well-defined isolation layers, make sure that you try to completely define the communication layers and formats between the client and server. If the BA’s are planning something new, have them run it by the entire team so that the team can discuss the ramifications on the architecture.
Define A Methodology And Stick To It
If you are going to do Agile or Scrum, then stick to it. If you are going to do Waterfall, then stick to it. If you are going to decide on daily standups, then stick to it.
Have The Environment Completely Set Up
Consultants get paid a lot of money, and their efforts are usually time-boxed. So, make sure that they are productive from day one. Have all user accounts set up. Have all of the software ready. If this software requires additional registration, then make sure that this is done. Make sure that there are enough licenses for the software, and make sure that support packages have been purchased.
Make sure that the computers have enough memory and enough free disk space. Developers need about 2gb of RAM and about 100gb of free hard drive space. Make sure that certain shared drives can be accessed.
Make sure that the security people in the building know that a team is starting, and to expect them. If a consultant is made to wait in the lobby while security tries to track down someone to sign them in, then this serves nobody.
Have Documentation Ready
Does the system have documentation? Use cases? Architecture docs? If not, then either prepare them or prepare for a steeper learning process.
Engage the Business Analysts and Business Users
I have talked about this before. If you are writing a trading system, then the developers should be able to have access to the traders. The developers should be able to peek over a trader’s shoulder while he is working. The developers should have a complete feel for the kind of system that a trader would like to have.
If there are BAs that the developers must interact with, then make sure that the devs and BAs have constant interaction. Make sure that the BAs know if some of their ideas will be difficult to implement.
Do Not Pair-Program Unless Absolutely Necessary
I continue to abhor pair programming. I think that it cuts down productivity in a big way. I think that the best development is done when the developer is “in the zone”, and does not have to expend energy explaining every move to someone else.
Instead, have design meetings and developer meetings. It does not have to be “Big Design Up Front”. However, if a developer is architecting a crucial module, then let him present the design to the entire team and get critiques before the effort is too far gone.
Always Have a Roadmap For Refactoring
Do you know why a product is being refactored? Does the business absolutely need it? Do you really need to rewrite an entire application from scratch?
Remember that, when you refactor an application, you need a plan to retain all of the business logic that is built in to the existing app.
Make sure that the code has comments. Make sure that there is plenty of technical documentation. Make sure that all of the business rules are documented.
Make sure that all dead code has been eliminated from the application. It is difficult to rearchitect a system if the hands of 30 different people have been in it over the years.
These are my ideal Rules of Engagement for any project that I will be on, either as a leader or as a hired hand. I would love to hear your comments.
©2006 Marc Adler - All Rights Reserved
My first engagement with Finetix has just ended, and it was an eye-opener in certain respects.
I have been thinking about what I would like to include in a retrospective to the client in order to help them manage future projects successfully. Instead of enumerating what I consider to be the positives and negatives of the project, I would like to add some of the aspects to my master “Lessons Learned” list, and also to reiterate some of my long-standing project-management processes.
1) Clearly Define Roles
2) Always Be Engaged
3) Make Sure Everyone Knows Everything
4) Define A Methodology And Stick To It
5) Have The Environment Completely Set Up
6) Have Documentation Ready
7) Engage the Business Analysts and Business Users
8) Do Not Pair-Program Unless Absolutely Necessary
9) Always Have a Roadmap For Refactoring
Clearly Define Roles
If you are bringing in consultants to lead the technical team, then tell your team members and enforce the leadership. If you are expecting your consultants to be short-term body-shoppers who are coding, then tell them this up front. Do not allow incorrect perceptions to pervade the group.
There will always be bruised feelings when you bring consultants on to a project in a leadership role. We consultants completely understand this. Nobody wants their work to be reevaluated and critiqued. If the consultants are being brought in to do rearchitecture, then they must be given the power to lead the effort.
Make it clear as to who holds the trump card.
Always Be Engaged
As a project manager, make sure that you know what all of your team members are doing, and make sure that all team members know what each other is doing. Make sure that the server side and client side teams communicate. Many server-side devs have also done GUI work and vice-versa.
If you have to support a legacy version of your product, then make sure that you are able to delegate that task to certain members of the team. Have a plan to get these “legacy developers” involved with the new development. The legacy devs are subject matter experts who are important to the whole team.
Make Sure Everyone Knows Everything
As mentioned above, do not isolate the groups. Involve the Business Analysts and Business Users where appropriate. Unless there are well-defined isolation layers, make sure that you try to completely define the communication layers and formats between the client and server. If the BA’s are planning something new, have them run it by the entire team so that the team can discuss the ramifications on the architecture.
Define A Methodology And Stick To It
If you are going to do Agile or Scrum, then stick to it. If you are going to do Waterfall, then stick to it. If you are going to decide on daily standups, then stick to it.
Have The Environment Completely Set Up
Consultants get paid a lot of money, and their efforts are usually time-boxed. So, make sure that they are productive from day one. Have all user accounts set up. Have all of the software ready. If this software requires additional registration, then make sure that this is done. Make sure that there are enough licenses for the software, and make sure that support packages have been purchased.
Make sure that the computers have enough memory and enough free disk space. Developers need about 2gb of RAM and about 100gb of free hard drive space. Make sure that certain shared drives can be accessed.
Make sure that the security people in the building know that a team is starting, and to expect them. If a consultant is made to wait in the lobby while security tries to track down someone to sign them in, then this serves nobody.
Have Documentation Ready
Does the system have documentation? Use cases? Architecture docs? If not, then either prepare them or prepare for a steeper learning process.
Engage the Business Analysts and Business Users
I have talked about this before. If you are writing a trading system, then the developers should be able to have access to the traders. The developers should be able to peek over a trader’s shoulder while he is working. The developers should have a complete feel for the kind of system that a trader would like to have.
If there are BAs that the developers must interact with, then make sure that the devs and BAs have constant interaction. Make sure that the BAs know if some of their ideas will be difficult to implement.
Do Not Pair-Program Unless Absolutely Necessary
I continue to abhor pair programming. I think that it cuts down productivity in a big way. I think that the best development is done when the developer is “in the zone”, and does not have to expend energy explaining every move to someone else.
Instead, have design meetings and developer meetings. It does not have to be “Big Design Up Front”. However, if a developer is architecting a crucial module, then let him present the design to the entire team and get critiques before the effort is too far gone.
Always Have a Roadmap For Refactoring
Do you know why a product is being refactored? Does the business absolutely need it? Do you really need to rewrite an entire application from scratch?
Remember that, when you refactor an application, you need a plan to retain all of the business logic that is built in to the existing app.
Make sure that the code has comments. Make sure that there is plenty of technical documentation. Make sure that all of the business rules are documented.
Make sure that all dead code has been eliminated from the application. It is difficult to rearchitect a system if the hands of 30 different people have been in it over the years.
These are my ideal Rules of Engagement for any project that I will be on, either as a leader or as a hired hand. I would love to hear your comments.
©2006 Marc Adler - All Rights Reserved
Friday, March 17, 2006
Transition #1
My last day in the land of the Freeborn is today. Good exposure to Credit Derivs.
Starting Monday at the home of the Big Mack. Enhancing an FX system.
©2006 Marc Adler - All Rights Reserved
Starting Monday at the home of the Big Mack. Enhancing an FX system.
©2006 Marc Adler - All Rights Reserved
Tuesday, March 14, 2006
Garden Leave
I rode on the train this morning with a neighbor who is a Managing Director at a Wall Street firm. He is switching companies, and just handed in his resignation. However, he does not start his new position for another 90 days.
It seems that most Wall Street companies are imposing a minimum number of days that you have to stay with a firm when you give your notice. In his case, he had to give 90 days notice. However, his current employer must pay him for the entire 90 days.
His current employer wants him out of the office as fast as possible, so that he does not have the chance to do any internal recruiting. So, he gets to sit at home for 3 months and collect a paycheck.
From what he told me, this practice has been prevalent in Europe, and is just starting to make the rounds in the United States. He told me that it is referred to as "Garden Leave", because the only thing you can do for 3 months is putt around in your garden.
©2006 Marc Adler - All Rights Reserved
It seems that most Wall Street companies are imposing a minimum number of days that you have to stay with a firm when you give your notice. In his case, he had to give 90 days notice. However, his current employer must pay him for the entire 90 days.
His current employer wants him out of the office as fast as possible, so that he does not have the chance to do any internal recruiting. So, he gets to sit at home for 3 months and collect a paycheck.
From what he told me, this practice has been prevalent in Europe, and is just starting to make the rounds in the United States. He told me that it is referred to as "Garden Leave", because the only thing you can do for 3 months is putt around in your garden.
©2006 Marc Adler - All Rights Reserved
"On Becoming a Quant" by Mark Joshi
This was an interesting post that I found on a financial forum. For all of you who have harbored the fantasy of becomign a quant, here is a treatise on what it is like in the real world. Thanks to Mark Joshi for writing this.
ON BECOMING A QUANT
MARK JOSHI
What does a quant do?
A quant designs and implements mathematical models for the pricing
of derivatives.
What sorts of quants are there?
(1) Front office/desk quant
(2) Model validating quant
(3) Research quant
(4) Quant developer
A desk quant implements pricing models directly used by traders.
Main plusses close to the money and opportunities to move into trading.
Minuses can be stressful and depending on the outfit may not involve
much research.
A model validation quant independently implements pricing models
in order to check that front office models are correct. Plusses more
relaxed, less stressful. Minusses model validation teams can be uninspired
and far from the money.
Research quant tries to invent new pricing approaches and sometimes
carries out blue-sky research. Plusses it’s interesting and you learn a
lot more. Minusses sometimes hard to justify your existence.
Quant developer – a glorified programmer but well-paid and easy to
find a job.
All forms of quants spend a large amount (i.e. more than half) their
time programming. However, implementing new models is interesting
in itself. The standard programming approach is object-oriented C++.
A wannabe quant must learn C++.
In the UK standard sources for job adverts are www.jobserve.com
search under ”quant”, the FT appointments section on a Thursday,
and www.wilmott.com has a jobs board. A lot of adverts are from
recruitment consultants rather than from banks. It’s important to
realize that the job may not even exist – the consultant wants to get
decent candidates that he can then try to place them in banks. The
consultant gets a commission from the bank if he can place you. They
tend to have short attention spans. If you do well at the first couple of
interviews then they will work hard to get you a good job but if you
don’t they will quickly lose interest. Also, be aware their agenda is to
get a good commission rather than to help you so they will push you
at jobs on that basis.
In fact, going via a recruitment consultant is the standard way to
get a job. Quants are generally not hired as a part of the on campus
recruitment process but instead hired as they are needed by the team.
Because of this it’s not a great idea to start applying a long time before
you want to start. Obviously personal contacts should be exploited
as much as possible. Banks tend not to be into paying expenses for
interviews. One therefore needs to go to London or New York and
attempt to get as many interviews as possible as quickly as possible.
What should one learn? Standard books are
• Hull - Options future and other derivatives – comprehensive
but low level mathematically and can be frustrating for pure
mathematicians
• Baxter and Rennie – accessible introduction to martingale approach
but oriented towards theory rather than practicalitues
• Wilmott (Derivatives) – good on the PDE approach but not so
good on other approaches.
My book will be published in early 2003 and I like it, of course.
Stochastic calculus is useful but not as important as it at first appears.
Standard texts are Oksendal, and Karatzas and Shreve. It’s
hard to find the time to pick it up on the job so it’s worth learning in
advance. It’s also worth spending some time going over basic probability
theory – eg Chung’s books.
Interviewers tend to care more about understanding the basics well
than on knowing a lot. It’s also important to demonstrate genuine
interest in the field. Read the Economist and the FT or Wall Street
Journal comprehensively. It’s not unusual to ask basic calculus or analysis
questions e.g. what is the integral of log x. Asking for a derivation
of the Black-Scholes equation is very common too. They always ask
you to explain your thesis so be prepared to be able to do this.
Generally, a PhD (or almost a PhD) is a necessity to get a quant
job. I would advise against starting before it’s awarded as it tends to
be hard to get it done whilst doing a busy job.
The main challenge for a pure mathematician is to be able to get
one’s hands dirty and learning to be more focussed on getting numeric
results than on fancy theories. The main way to do this is to implement
pricing models for practice. If this doesn’t appeal you aren’t suited to
being a quant. There are quite a few ex-pure mathematicians working
in the city so it can certainly be done but there is some prejudice
towards applied maths and physics people.
How much does a quant earn? A quant with no experience will
generally get between 35 and 50k pounds. This will generally go up
fairly rapidly. Bonuses are generally a large component of total salary.
How hard does a quant work? This varies a lot. At RBS we get in
between 8.30 and 9 and go home around 6pm. The pressure varies.
Some of the American banks expect much longer hours. Wall St tends
to be more demanding than the City. In London 5 to 6 weeks holidays
is standard. In the US 2 to 3 is standard.
©2006 Marc Adler - All Rights Reserved
ON BECOMING A QUANT
MARK JOSHI
What does a quant do?
A quant designs and implements mathematical models for the pricing
of derivatives.
What sorts of quants are there?
(1) Front office/desk quant
(2) Model validating quant
(3) Research quant
(4) Quant developer
A desk quant implements pricing models directly used by traders.
Main plusses close to the money and opportunities to move into trading.
Minuses can be stressful and depending on the outfit may not involve
much research.
A model validation quant independently implements pricing models
in order to check that front office models are correct. Plusses more
relaxed, less stressful. Minusses model validation teams can be uninspired
and far from the money.
Research quant tries to invent new pricing approaches and sometimes
carries out blue-sky research. Plusses it’s interesting and you learn a
lot more. Minusses sometimes hard to justify your existence.
Quant developer – a glorified programmer but well-paid and easy to
find a job.
All forms of quants spend a large amount (i.e. more than half) their
time programming. However, implementing new models is interesting
in itself. The standard programming approach is object-oriented C++.
A wannabe quant must learn C++.
In the UK standard sources for job adverts are www.jobserve.com
search under ”quant”, the FT appointments section on a Thursday,
and www.wilmott.com has a jobs board. A lot of adverts are from
recruitment consultants rather than from banks. It’s important to
realize that the job may not even exist – the consultant wants to get
decent candidates that he can then try to place them in banks. The
consultant gets a commission from the bank if he can place you. They
tend to have short attention spans. If you do well at the first couple of
interviews then they will work hard to get you a good job but if you
don’t they will quickly lose interest. Also, be aware their agenda is to
get a good commission rather than to help you so they will push you
at jobs on that basis.
In fact, going via a recruitment consultant is the standard way to
get a job. Quants are generally not hired as a part of the on campus
recruitment process but instead hired as they are needed by the team.
Because of this it’s not a great idea to start applying a long time before
you want to start. Obviously personal contacts should be exploited
as much as possible. Banks tend not to be into paying expenses for
interviews. One therefore needs to go to London or New York and
attempt to get as many interviews as possible as quickly as possible.
What should one learn? Standard books are
• Hull - Options future and other derivatives – comprehensive
but low level mathematically and can be frustrating for pure
mathematicians
• Baxter and Rennie – accessible introduction to martingale approach
but oriented towards theory rather than practicalitues
• Wilmott (Derivatives) – good on the PDE approach but not so
good on other approaches.
My book will be published in early 2003 and I like it, of course.
Stochastic calculus is useful but not as important as it at first appears.
Standard texts are Oksendal, and Karatzas and Shreve. It’s
hard to find the time to pick it up on the job so it’s worth learning in
advance. It’s also worth spending some time going over basic probability
theory – eg Chung’s books.
Interviewers tend to care more about understanding the basics well
than on knowing a lot. It’s also important to demonstrate genuine
interest in the field. Read the Economist and the FT or Wall Street
Journal comprehensively. It’s not unusual to ask basic calculus or analysis
questions e.g. what is the integral of log x. Asking for a derivation
of the Black-Scholes equation is very common too. They always ask
you to explain your thesis so be prepared to be able to do this.
Generally, a PhD (or almost a PhD) is a necessity to get a quant
job. I would advise against starting before it’s awarded as it tends to
be hard to get it done whilst doing a busy job.
The main challenge for a pure mathematician is to be able to get
one’s hands dirty and learning to be more focussed on getting numeric
results than on fancy theories. The main way to do this is to implement
pricing models for practice. If this doesn’t appeal you aren’t suited to
being a quant. There are quite a few ex-pure mathematicians working
in the city so it can certainly be done but there is some prejudice
towards applied maths and physics people.
How much does a quant earn? A quant with no experience will
generally get between 35 and 50k pounds. This will generally go up
fairly rapidly. Bonuses are generally a large component of total salary.
How hard does a quant work? This varies a lot. At RBS we get in
between 8.30 and 9 and go home around 6pm. The pressure varies.
Some of the American banks expect much longer hours. Wall St tends
to be more demanding than the City. In London 5 to 6 weeks holidays
is standard. In the US 2 to 3 is standard.
©2006 Marc Adler - All Rights Reserved
Monday, March 13, 2006
The Wall Street Stack Revisited
Chris pointed me to an article on the MSDN/Smart Client page. A startup company called IdeaBlade is offering much of the business object and form-binding backbone that all of us have developed in the past.
I would be interested to hear your opinions of it.
©2006 Marc Adler - All Rights Reserved
I would be interested to hear your opinions of it.
©2006 Marc Adler - All Rights Reserved
Lepus Reports
Allow me to give a shout out to Lepus Reports. I just discovered an archive of past Lepus Reports on my current client's Intranet, and have been devouring each issue with relish.
They release two reports per month; a Research Report that contains about 10 articles dealing with a specific area of financial IT, and a briefer Management Report. For instance, one article might give an overview of ECNs, talk about the current trends in ECN usage, and give a brief overview of the various vendors in that space. They will also survey a number of financial firms to find out what they are currently using.
The last few pages of each report are devoted to news, so you can find out about new products, who has changed companies, and who has bought out whom.
If I were a financial IT consultant who changed clients every few months (which I am) and needed to get up to speed on a certain domain, I would certainly reach for a Lepus Report to get a quick backgrounder.
Note: I have no connection with Lepus, other than being a satisfied reader.
©2006 Marc Adler - All Rights Reserved
They release two reports per month; a Research Report that contains about 10 articles dealing with a specific area of financial IT, and a briefer Management Report. For instance, one article might give an overview of ECNs, talk about the current trends in ECN usage, and give a brief overview of the various vendors in that space. They will also survey a number of financial firms to find out what they are currently using.
The last few pages of each report are devoted to news, so you can find out about new products, who has changed companies, and who has bought out whom.
If I were a financial IT consultant who changed clients every few months (which I am) and needed to get up to speed on a certain domain, I would certainly reach for a Lepus Report to get a quick backgrounder.
Note: I have no connection with Lepus, other than being a satisfied reader.
©2006 Marc Adler - All Rights Reserved
Subscribe to:
Posts (Atom)
