Friday, March 24, 2006

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!

Sunday, March 19, 2006

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 Roles2) Always Be Engaged3) Make Sure Everyone Knows Everything4) Define A Methodology And Stick To It5) Have The Environment Completely Set Up6) Have Documentation Ready7) Engage the Business Analysts and Business Users8) Do Not Pair-Program Unless Absolutely Necessary9) 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.

Tuesday, March 14, 2006

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.

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 QUANTMARK JOSHI

What does a quant do?

A quant designs and implements mathematical models for the pricingof derivatives.

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

A model validation quant independently implements pricing modelsin order to check that front office models are correct. Plusses morerelaxed, less stressful. Minusses model validation teams can be uninspiredand far from the money.

Research quant tries to invent new pricing approaches and sometimescarries out blue-sky research. Plusses it’s interesting and you learn alot more. Minusses sometimes hard to justify your existence.Quant developer – a glorified programmer but well-paid and easy tofind a job.

All forms of quants spend a large amount (i.e. more than half) theirtime programming. However, implementing new models is interestingin 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.comsearch under ”quant”, the FT appointments section on a Thursday,and www.wilmott.com has a jobs board. A lot of adverts are fromrecruitment consultants rather than from banks. It’s important torealize that the job may not even exist – the consultant wants to getdecent candidates that he can then try to place them in banks. Theconsultant gets a commission from the bank if he can place you. Theytend to have short attention spans. If you do well at the first couple ofinterviews then they will work hard to get you a good job but if youdon’t they will quickly lose interest. Also, be aware their agenda is toget a good commission rather than to help you so they will push youat jobs on that basis.

In fact, going via a recruitment consultant is the standard way toget a job. Quants are generally not hired as a part of the on campusrecruitment 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 beforeyou want to start. Obviously personal contacts should be exploitedas much as possible. Banks tend not to be into paying expenses forinterviews. One therefore needs to go to London or New York andattempt to get as many interviews as possible as quickly as possible.What should one learn? Standard books are

• Hull - Options future and other derivatives – comprehensivebut low level mathematically and can be frustrating for puremathematicians

• Wilmott (Derivatives) – good on the PDE approach but not sogood 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’shard to find the time to pick it up on the job so it’s worth learning inadvance. It’s also worth spending some time going over basic probabilitytheory – eg Chung’s books.

Interviewers tend to care more about understanding the basics wellthan on knowing a lot. It’s also important to demonstrate genuineinterest in the field. Read the Economist and the FT or Wall StreetJournal comprehensively. It’s not unusual to ask basic calculus or analysisquestions e.g. what is the integral of log x. Asking for a derivationof the Black-Scholes equation is very common too. They always askyou 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 quantjob. I would advise against starting before it’s awarded as it tends tobe hard to get it done whilst doing a busy job.

The main challenge for a pure mathematician is to be able to getone’s hands dirty and learning to be more focussed on getting numericresults than on fancy theories. The main way to do this is to implementpricing models for practice. If this doesn’t appeal you aren’t suited tobeing a quant. There are quite a few ex-pure mathematicians workingin the city so it can certainly be done but there is some prejudicetowards applied maths and physics people.

How much does a quant earn? A quant with no experience willgenerally get between 35 and 50k pounds. This will generally go upfairly rapidly. Bonuses are generally a large component of total salary.How hard does a quant work? This varies a lot. At RBS we get inbetween 8.30 and 9 and go home around 6pm. The pressure varies.Some of the American banks expect much longer hours. Wall St tendsto be more demanding than the City. In London 5 to 6 weeks holidaysis standard. In the US 2 to 3 is standard.

Monday, March 13, 2006

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.

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.