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
Wednesday, February 08, 2006
Thursday, February 02, 2006
A Data Point - Senior .NET Arch/Dev Salary
Even though my resume is not in the "active" state on Monster and Dice, I still get a ton of calls from headhunters. Since coming out of my New Jersey territory, and working in New York, I now pay attention to what Wall Street dev managers, architects, and developers are making. After all, when we try to recruit candidates for Finetix, we need to be a little more than competitve with the current batch of companies.
Perhaps everyone have just gotten their new budgets approved ... perhaps it is all of the annual February job movement taking place, and new hires want to re-stock their technical teams .... but this week has been ridiculous in the number of calls and emails that I have been getting for Wall Street firms looking for solid technical talent. The same thing must be happening over in the City of London.
On Wall Street, it seems that the base salary for a senior .NET and Java architect/developer is $150,000. This must mean that the salary for a City of London position is around £100,000. (Can any London-based developer confirm this?)
Bonus is everything on Wall Street. It was shocking to hear that the bonuses for average developers at my current client around around 10%. Lehman's bonus are much, much higher, but you have to work every Saturday. UBS is around 40%.
I would love to get more data points. Please feel free to comment.
©2006 Marc Adler - All Rights Reserved
Perhaps everyone have just gotten their new budgets approved ... perhaps it is all of the annual February job movement taking place, and new hires want to re-stock their technical teams .... but this week has been ridiculous in the number of calls and emails that I have been getting for Wall Street firms looking for solid technical talent. The same thing must be happening over in the City of London.
On Wall Street, it seems that the base salary for a senior .NET and Java architect/developer is $150,000. This must mean that the salary for a City of London position is around £100,000. (Can any London-based developer confirm this?)
Bonus is everything on Wall Street. It was shocking to hear that the bonuses for average developers at my current client around around 10%. Lehman's bonus are much, much higher, but you have to work every Saturday. UBS is around 40%.
I would love to get more data points. Please feel free to comment.
©2006 Marc Adler - All Rights Reserved
Monday, January 30, 2006
A Wish - Validators for Properties in C#
While writing a validation framework for a whole bunch of business objects this weekend, I wish I would have had the following in C#/.NET
public double Notional
{
get
{
return this._notional;
}
set
{
this._notional = value;
}
validate
{
if (this._notional <>
{
this.AddBrokenRule("A Buyer's notional cannot be negative");
return false;
}
return true;
}
}
If I called businessObject.IsValid, then all properties of the businessObject that implemented validate would be tested. Each object would automatically contain an IList of all broken business rules.
There would be support for this in the Visual Studio designer, so that I could created a resource-based string for each error message.
©2006 Marc Adler - All Rights Reserved
public double Notional
{
get
{
return this._notional;
}
set
{
this._notional = value;
}
validate
{
if (this._notional <>
{
this.AddBrokenRule("A Buyer's notional cannot be negative");
return false;
}
return true;
}
}
If I called businessObject.IsValid, then all properties of the businessObject that implemented validate would be tested. Each object would automatically contain an IList of all broken business rules.
There would be support for this in the Visual Studio designer, so that I could created a resource-based string for each error message.
©2006 Marc Adler - All Rights Reserved
Boy, Things Have Changed!
When I left my position as Technical Director of a new division of SGP in March 2002, I knew that the market was starting to turn bad for consultants. Even the ones who were "known quantities" out there. I left SGP because I wanted to fulfill a dream and persue a master's degree in Percussion Performance. I had never had any downtime since graduating college and the pull of music was becoming stronger.
However, on my first day of freedom, at 8:30 AM (they did not even wait until 9), I got a call from an old colleague of mine who was forming a new company and wanted me to be CTO of it. This position carried me until the summer of 2003, when we sold the company to our biggest competitor.
During this time, I heard all sorts of horror stories about the consulting market. Nobody could find a job anywhere! At the apex of this madness, the New York Times magazine ran a story about a former high-flyer in the Internet world who was working at The Gap, selling jeans and trying to eke out a living. After we sold the company, I had about 2 months where I experienced the depths of the consulting marketplace. People with 10 years of heavy C++ were being offered $35 an hour, and were happy to take it!
Fast forward to January 2006.....
Jobs seems to be abundant in the IT field. How abundant? I just posted a help-wanted ad for Finetix, and I received a grand total of 2 replies, one of which was from a glorified computer technician. Now, Finetix happens to be a good company to work for. They have interesting projects in the Wall Street area and they pay about 10-15% over the prevailing market rate in order to get the best talent that they could find. But, seriously... 2 replies!!!
Anyone interested in working for Finetix? Send your resume to me at magmasystems@yahoo.com.
©2006 Marc Adler - All Rights Reserved
However, on my first day of freedom, at 8:30 AM (they did not even wait until 9), I got a call from an old colleague of mine who was forming a new company and wanted me to be CTO of it. This position carried me until the summer of 2003, when we sold the company to our biggest competitor.
During this time, I heard all sorts of horror stories about the consulting market. Nobody could find a job anywhere! At the apex of this madness, the New York Times magazine ran a story about a former high-flyer in the Internet world who was working at The Gap, selling jeans and trying to eke out a living. After we sold the company, I had about 2 months where I experienced the depths of the consulting marketplace. People with 10 years of heavy C++ were being offered $35 an hour, and were happy to take it!
Fast forward to January 2006.....
Jobs seems to be abundant in the IT field. How abundant? I just posted a help-wanted ad for Finetix, and I received a grand total of 2 replies, one of which was from a glorified computer technician. Now, Finetix happens to be a good company to work for. They have interesting projects in the Wall Street area and they pay about 10-15% over the prevailing market rate in order to get the best talent that they could find. But, seriously... 2 replies!!!
Anyone interested in working for Finetix? Send your resume to me at magmasystems@yahoo.com.
©2006 Marc Adler - All Rights Reserved
Friday, January 13, 2006
User Groups in the NYC/NJ Area
Here are user groups of interest that one can attend after work if you are in the NYC/NJ area.
New York City .NET Developers Group
The meetings are usually held at Microsoft, 1290 Avenue of the Americas (the AXA building - bet. 51st/52nd Sts.), 6th floor
The Design Patterns Study Group of New York
The weekly meeting are held at various places, depending on which subgroup you belong to.
New Jersey .NET Developers Group
The monthly meetings are held at the Microsoft NJ Office in Iselin.
©2006 Marc Adler - All Rights Reserved
New York City .NET Developers Group
The meetings are usually held at Microsoft, 1290 Avenue of the Americas (the AXA building - bet. 51st/52nd Sts.), 6th floor
The Design Patterns Study Group of New York
The weekly meeting are held at various places, depending on which subgroup you belong to.
New Jersey .NET Developers Group
The monthly meetings are held at the Microsoft NJ Office in Iselin.
©2006 Marc Adler - All Rights Reserved
Monday, January 09, 2006
MFC to C#/.NET Porting Service???
Are people out there still learning C++ and MFC? I can't imagine that they are. If you are a financial services company, and you have a big application written in MFC (let's forget about ATL and WTL right now), how difficult is it for you to find an MFC developer to enhance the application?
Would you pay for a porting company to transform the application into a C#/.NET application? Or, if there was a product available, would you pay for a .NET framework that is quasi-compatible with MFC?
Maybe Finetix will give me some seed money for this!
©2006 Marc Adler - All Rights Reserved
Would you pay for a porting company to transform the application into a C#/.NET application? Or, if there was a product available, would you pay for a .NET framework that is quasi-compatible with MFC?
Maybe Finetix will give me some seed money for this!
©2006 Marc Adler - All Rights Reserved
Monday, December 19, 2005
General Contractors
My Finetix colleague, Chris, just reminded me of the lunchtime conversation we had a few days ago with one of our good friends from RiskFocus. It got me thinking about an interesting model for development.
Think of what a General Contractor does when you do construction on a home. He gets (hopefully) the best-of-breed specialists to perform certain functions. He has one company to do the foundation, another to do the framing, another to do the electrical wiring, and another to do the sheet rock and spackling. Each of these tasks is done efficiently by the tradesman, and then it is understood that they move on to another construction job.
I am wondering if anyone has followed this model in developing systems. A "General Contractor" gets the best consultants around to perform a specific specialist task, something that they do best. The job lasts for one month, and then the contractor moves to a different development job. There would be a specialist to write the framework, a specialist to plug in the security and entitlements, a specialist to write the Web Services and fix any interoperability issues, a specialist to write the calculation engines, and then a GUI specialist to plug in a front end. Each member of this well-oiled team would be versed in the various interfaces and abstractions that the other members of the team use, so that the security specialist would come in, and know immediately where to hook in his stuff to various parts of the framework.
The members of the team would rotate amongst the various specialties so they do not end up getting tagged as a master in only a single discipline.
I have never seen this model being used, but I would be curious if anyone has ever tried it.
Your comments are welcome.
©2005 Marc Adler - All Rights Reserved
Think of what a General Contractor does when you do construction on a home. He gets (hopefully) the best-of-breed specialists to perform certain functions. He has one company to do the foundation, another to do the framing, another to do the electrical wiring, and another to do the sheet rock and spackling. Each of these tasks is done efficiently by the tradesman, and then it is understood that they move on to another construction job.
I am wondering if anyone has followed this model in developing systems. A "General Contractor" gets the best consultants around to perform a specific specialist task, something that they do best. The job lasts for one month, and then the contractor moves to a different development job. There would be a specialist to write the framework, a specialist to plug in the security and entitlements, a specialist to write the Web Services and fix any interoperability issues, a specialist to write the calculation engines, and then a GUI specialist to plug in a front end. Each member of this well-oiled team would be versed in the various interfaces and abstractions that the other members of the team use, so that the security specialist would come in, and know immediately where to hook in his stuff to various parts of the framework.
The members of the team would rotate amongst the various specialties so they do not end up getting tagged as a master in only a single discipline.
I have never seen this model being used, but I would be curious if anyone has ever tried it.
Your comments are welcome.
©2005 Marc Adler - All Rights Reserved
Sunday, November 27, 2005
The Wall Street Stack
It has been done plenty of times on Wall Street..... what I call the Wall Street Stack.
I just came off of a large project where I architected (yet another) one. I am current involved in one now. So are plenty of other people that I know in other companies.
Everyone's trading applications seems to be the same. Here are the standard elements:
1) The UI layer. The UI layer is usually designed around the Model-View-Controller pattern. It generally uses some third-party UI suite, such as Infragistics, Component One, or Syncfusion.
2) The UI usually contains an Outlook-style navigation bar on the left side. On the right is usually an MDI-ish area. There are multiple tabbed controls, each containing a grid control. The grid is a respresentation of the underlying business objects.
3) Filter criteria that is used to filter the results on the grid. The filter UI is usually placed on the same panel as the grid and consists of a number of comboboxes and edit fields that represent dates and static criteria. Filters can usually be translated into an SQL statement.... a dataview-like pattern can be applied to the underlying model to produce a filtered view.
4) User preferences and workspace persistence. Users can save the layout of the workspace, and load the layout when they log onto a new session from any machine.
5) Entitlements by role. Entitlements control various aspects of the UI, such as what menus, toolbar buttons, and controls are available to the user.
6) A Data layer that sits between the UI layer and the middle-tier. The data layer can contain a business facade, smart business objects (that are decorated with .NET attributes), a data access layer (contains a reference to the cache), and service providers that interface with a database and/or a middle-tier. The data layer can communicate with the middle-tier in both synchronous and asynchronous fashion.
7) Middle-tier (usually Java-based) that accesses the underlying database. Communication with the middle-tier is through some variant of XML (usually SOAP). (Sorry, .NET middle-tiers have not caught on yet in Wall Street ... I cite projects at Lehman, Wachovia, Citicorp, Goldman...)
8) Schemas shared between the client and middle-tier.
9) Subscription to asynchronous events, usually by some mechanism as a message bus (Tibco RV or EMS), or Smart Sockets (which is now owned by Tibco). When something happens to the underlying data, the middle-tier will broadcast an event to all of the clients that are hooked up to it. Each client has something that I call a "service agent", which is like a web service in reverse. The service agent receives the subscription event, and propogates the evented data up the chain.
10) A rich event manager. The event manager can be thought of as a mini-Tibco that resides totally within the client. The event manager should support wildcarding.
This stack is being implemented over and over again. The closest thing that I have seen to a corporate standard is the OCEAN framework that Goldman has.
There has to be a vendor who can commercialize this stack and sell it across the various financial companies. Anyone want to start a company with me????
As an aside, the Microsoft Composite Application Block bears close watching. However, it is only available for .NET 2.0. Many of the current .NET-based projects are still using 1.1.
©2005 Marc Adler - All Rights Reserved
I just came off of a large project where I architected (yet another) one. I am current involved in one now. So are plenty of other people that I know in other companies.
Everyone's trading applications seems to be the same. Here are the standard elements:
1) The UI layer. The UI layer is usually designed around the Model-View-Controller pattern. It generally uses some third-party UI suite, such as Infragistics, Component One, or Syncfusion.
2) The UI usually contains an Outlook-style navigation bar on the left side. On the right is usually an MDI-ish area. There are multiple tabbed controls, each containing a grid control. The grid is a respresentation of the underlying business objects.
3) Filter criteria that is used to filter the results on the grid. The filter UI is usually placed on the same panel as the grid and consists of a number of comboboxes and edit fields that represent dates and static criteria. Filters can usually be translated into an SQL statement.... a dataview-like pattern can be applied to the underlying model to produce a filtered view.
4) User preferences and workspace persistence. Users can save the layout of the workspace, and load the layout when they log onto a new session from any machine.
5) Entitlements by role. Entitlements control various aspects of the UI, such as what menus, toolbar buttons, and controls are available to the user.
6) A Data layer that sits between the UI layer and the middle-tier. The data layer can contain a business facade, smart business objects (that are decorated with .NET attributes), a data access layer (contains a reference to the cache), and service providers that interface with a database and/or a middle-tier. The data layer can communicate with the middle-tier in both synchronous and asynchronous fashion.
7) Middle-tier (usually Java-based) that accesses the underlying database. Communication with the middle-tier is through some variant of XML (usually SOAP). (Sorry, .NET middle-tiers have not caught on yet in Wall Street ... I cite projects at Lehman, Wachovia, Citicorp, Goldman...)
8) Schemas shared between the client and middle-tier.
9) Subscription to asynchronous events, usually by some mechanism as a message bus (Tibco RV or EMS), or Smart Sockets (which is now owned by Tibco). When something happens to the underlying data, the middle-tier will broadcast an event to all of the clients that are hooked up to it. Each client has something that I call a "service agent", which is like a web service in reverse. The service agent receives the subscription event, and propogates the evented data up the chain.
10) A rich event manager. The event manager can be thought of as a mini-Tibco that resides totally within the client. The event manager should support wildcarding.
This stack is being implemented over and over again. The closest thing that I have seen to a corporate standard is the OCEAN framework that Goldman has.
There has to be a vendor who can commercialize this stack and sell it across the various financial companies. Anyone want to start a company with me????
As an aside, the Microsoft Composite Application Block bears close watching. However, it is only available for .NET 2.0. Many of the current .NET-based projects are still using 1.1.
©2005 Marc Adler - All Rights Reserved
The Wall Street Stack
It has been done plenty of times on Wall Street..... what I call the Wall Street Stack.
I just came off of a large project where I architected (yet another) one. I am current involved in one now. So are plenty of other people that I know in other companies.
Everyone's trading applications seems to be the same. Here are the standard elements:
1) The UI layer. The UI layer is usually designed around the Model-View-Controller pattern. It generally uses some third-party UI suite, such as Infragistics, Component One, or Syncfusion.
2) The UI usually contains an Outlook-style navigation bar on the left side. On the right is usually an MDI-ish area. There are multiple tabbed controls, each containing a grid control. The grid is a respresentation of the underlying business objects.
3) Filter criteria that is used to filter the results on the grid. The filter UI is usually placed on the same panel as the grid and consists of a number of comboboxes and edit fields that represent dates and static criteria. Filters can usually be translated into an SQL statement.... a dataview-like pattern can be applied to the underlying model to produce a filtered view.
4) User preferences and workspace persistence. Users can save the layout of the workspace, and load the layout when they log onto a new session from any machine.
5) Entitlements by role. Entitlements control various aspects of the UI, such as what menus, toolbar buttons, and controls are available to the user.
6) A Data layer that sits between the UI layer and the middle-tier. The data layer can contain a business facade, smart business objects (that are decorated with .NET attributes), a data access layer (contains a reference to the cache), and service providers that interface with a database and/or a middle-tier. The data layer can communicate with the middle-tier in both synchronous and asynchronous fashion.
7) Middle-tier (usually Java-based) that accesses the underlying database. Communication with the middle-tier is through some variant of XML (usually SOAP). (Sorry, .NET middle-tiers have not caught on yet in Wall Street ... I cite projects at Lehman, Wachovia, Citicorp, Goldman...)
8) Schemas shared between the client and middle-tier.
9) Subscription to asynchronous events, usually by some mechanism as a message bus (Tibco RV or EMS), or Smart Sockets (which is now owned by Tibco). When something happens to the underlying data, the middle-tier will broadcast an event to all of the clients that are hooked up to it. Each client has something that I call a "service agent", which is like a web service in reverse. The service agent receives the subscription event, and propogates the evented data up the chain.
10) A rich event manager. The event manager can be thought of as a mini-Tibco that resides totally within the client. The event manager should support wildcarding.
This stack is being implemented over and over again. The closest thing that I have seen to a corporate standard is the OCEAN framework that Goldman has.
There has to be a vendor who can commercialize this stack and sell it across the various financial companies. Anyone want to start a company with me????
As an aside, the Microsoft Composite Application Block bears close watching. However, it is only available for .NET 2.0. Many of the current .NET-based projects are still using 1.1.
©2005 Marc Adler - All Rights Reserved
I just came off of a large project where I architected (yet another) one. I am current involved in one now. So are plenty of other people that I know in other companies.
Everyone's trading applications seems to be the same. Here are the standard elements:
1) The UI layer. The UI layer is usually designed around the Model-View-Controller pattern. It generally uses some third-party UI suite, such as Infragistics, Component One, or Syncfusion.
2) The UI usually contains an Outlook-style navigation bar on the left side. On the right is usually an MDI-ish area. There are multiple tabbed controls, each containing a grid control. The grid is a respresentation of the underlying business objects.
3) Filter criteria that is used to filter the results on the grid. The filter UI is usually placed on the same panel as the grid and consists of a number of comboboxes and edit fields that represent dates and static criteria. Filters can usually be translated into an SQL statement.... a dataview-like pattern can be applied to the underlying model to produce a filtered view.
4) User preferences and workspace persistence. Users can save the layout of the workspace, and load the layout when they log onto a new session from any machine.
5) Entitlements by role. Entitlements control various aspects of the UI, such as what menus, toolbar buttons, and controls are available to the user.
6) A Data layer that sits between the UI layer and the middle-tier. The data layer can contain a business facade, smart business objects (that are decorated with .NET attributes), a data access layer (contains a reference to the cache), and service providers that interface with a database and/or a middle-tier. The data layer can communicate with the middle-tier in both synchronous and asynchronous fashion.
7) Middle-tier (usually Java-based) that accesses the underlying database. Communication with the middle-tier is through some variant of XML (usually SOAP). (Sorry, .NET middle-tiers have not caught on yet in Wall Street ... I cite projects at Lehman, Wachovia, Citicorp, Goldman...)
8) Schemas shared between the client and middle-tier.
9) Subscription to asynchronous events, usually by some mechanism as a message bus (Tibco RV or EMS), or Smart Sockets (which is now owned by Tibco). When something happens to the underlying data, the middle-tier will broadcast an event to all of the clients that are hooked up to it. Each client has something that I call a "service agent", which is like a web service in reverse. The service agent receives the subscription event, and propogates the evented data up the chain.
10) A rich event manager. The event manager can be thought of as a mini-Tibco that resides totally within the client. The event manager should support wildcarding.
This stack is being implemented over and over again. The closest thing that I have seen to a corporate standard is the OCEAN framework that Goldman has.
There has to be a vendor who can commercialize this stack and sell it across the various financial companies. Anyone want to start a company with me????
As an aside, the Microsoft Composite Application Block bears close watching. However, it is only available for .NET 2.0. Many of the current .NET-based projects are still using 1.1.
©2005 Marc Adler - All Rights Reserved
Sunday, November 13, 2005
Full-Layer vs Bottom-Up Reachitecture and Scrum
Mission
To reengineer a credit derivates trading system using Scrum. (30-day sprints)
Findings
The existing application is somewhat monolithic, with direct database access from the UI layer, and business rules embedded in the UI.
Things to consider
1) The users want to see visible functionality after each sprint. We need to rearchitect, but our refactoring must not affect the current UI.
2) We need to implement new structured products after the 3rd sprint.
Question
Would you rearchitect from the bottom up and devote each sprint to deliver a fully-tested foundation layer, working your way up until you hit the UI layer? Or, would each sprint consist of implementing the entire stack with ever-increasing functionality?
I would love to hear your opinions.
©2005 Marc Adler - All Rights Reserved
To reengineer a credit derivates trading system using Scrum. (30-day sprints)
Findings
The existing application is somewhat monolithic, with direct database access from the UI layer, and business rules embedded in the UI.
Things to consider
1) The users want to see visible functionality after each sprint. We need to rearchitect, but our refactoring must not affect the current UI.
2) We need to implement new structured products after the 3rd sprint.
Question
Would you rearchitect from the bottom up and devote each sprint to deliver a fully-tested foundation layer, working your way up until you hit the UI layer? Or, would each sprint consist of implementing the entire stack with ever-increasing functionality?
I would love to hear your opinions.
©2005 Marc Adler - All Rights Reserved
Microsoft Discovers Scrum
http://developers.slashdot.org/developers/05/11/13/0545244.shtml?tid=109&tid=8
©2005 Marc Adler - All Rights Reserved
©2005 Marc Adler - All Rights Reserved
Friday, November 11, 2005
Bovine Memories
Posting about my Microsoft contract brought back some interesting memories.
When I started the Microsoft contract to write some GUI-based management tools for their new SQL Server, Microsoft and IBM were still putting the finishing touches on OS/2 Presentation Manager. So, I started writing the software using an internal Microsoft character windowing system called COW .. short for Character-Oriented Windows. This was the only user interface system that MS had for OS/2. (Remember, SQL Server started life as an OS/2 product.) COW was used most notably in OS/2's LAN Manager. I forgot what the API was like, but I still have all my COW libraries and docs on 5 1/4" floppies in a filing cabinet... I just can't bear to part with those disks!
I used to get these 100 lb boxes shipped to me every week from Microsoft. Tons of manuals for SQL Server, OS/2 PM, LAN Manager, OS/2, etc. Thankfully, these went into the trash can a few years ago.
My manager on that consulting contract, Bob Muglia, is now a bigwig at Microsoft. He just got another bump in rank in the most recent corporate restructing at MS.
My experience with giving MS a fixed-price contract taught me that time-and-materials is the only way to go! It didn't help that Microsoft was in a big pissing match at the time with Sybase.
©2005 Marc Adler - All Rights Reserved
When I started the Microsoft contract to write some GUI-based management tools for their new SQL Server, Microsoft and IBM were still putting the finishing touches on OS/2 Presentation Manager. So, I started writing the software using an internal Microsoft character windowing system called COW .. short for Character-Oriented Windows. This was the only user interface system that MS had for OS/2. (Remember, SQL Server started life as an OS/2 product.) COW was used most notably in OS/2's LAN Manager. I forgot what the API was like, but I still have all my COW libraries and docs on 5 1/4" floppies in a filing cabinet... I just can't bear to part with those disks!
I used to get these 100 lb boxes shipped to me every week from Microsoft. Tons of manuals for SQL Server, OS/2 PM, LAN Manager, OS/2, etc. Thankfully, these went into the trash can a few years ago.
My manager on that consulting contract, Bob Muglia, is now a bigwig at Microsoft. He just got another bump in rank in the most recent corporate restructing at MS.
My experience with giving MS a fixed-price contract taught me that time-and-materials is the only way to go! It didn't help that Microsoft was in a big pissing match at the time with Sybase.
©2005 Marc Adler - All Rights Reserved
Wednesday, November 09, 2005
Just Who Do You Think You Are! (Part 4)
The left episode left Marc writing Windows-based equity workstations for Goldman by day, and packing word processors and text editors at night. (Because the ME Text Editor was one of the first 50 applications written for OS/2, Marc got to go down and show the editor at the IBM OS/2 booth at 1988 Spring COMDEX... learning OS/2 turned out to be a good move, as we shall see in a minute.)
Two opportunities came along at the same time that Marc could not pass up. Marc's wife was a Cobol/CICS for Drexel Burnham at the time (remember Michael Milkin???). Somehow, her boss's boss found out that there was a developer who was writing Windows software for Goldman at the time, and developer who could be enticed away for a certain sum of money. In addition, a new development manager who had just been hired by Microsoft had been looking for an OS/2/PM developer who could help him write software for his new group. Marc could not refuse either, so he accepted both!!!
So, now it was writing a DOS and Windows trading system for Drexel, and helping Microsoft write software for a product that they had licensed from Sybase and renamed.... SQL Server. Marc also started writing articles for Microsoft Systems Journal, which was run by the great Tony Rizzo, bless his soul!!!
Believe it or not, the Drexel contract was the more interesting of the two by a longshot! The problem was that, whatever was written for the Windows version of the trading system had to be replicated on the DOS version as well.... the traders had laptops that could not run Windows very well.
So, Marc had an idea..... why not write the Windows-based trading system in C, using the Windows API. And, for the DOS version, use the same API. This involved reimplementing the Windows API in a DOS library. This led to another product.... the Magma Extensible Window and Event Library... or MEWEL for short.
Next chapter.... MEWEL kicks Magma Systems into high gear....
©2005 Marc Adler - All Rights Reserved
Two opportunities came along at the same time that Marc could not pass up. Marc's wife was a Cobol/CICS for Drexel Burnham at the time (remember Michael Milkin???). Somehow, her boss's boss found out that there was a developer who was writing Windows software for Goldman at the time, and developer who could be enticed away for a certain sum of money. In addition, a new development manager who had just been hired by Microsoft had been looking for an OS/2/PM developer who could help him write software for his new group. Marc could not refuse either, so he accepted both!!!
So, now it was writing a DOS and Windows trading system for Drexel, and helping Microsoft write software for a product that they had licensed from Sybase and renamed.... SQL Server. Marc also started writing articles for Microsoft Systems Journal, which was run by the great Tony Rizzo, bless his soul!!!
Believe it or not, the Drexel contract was the more interesting of the two by a longshot! The problem was that, whatever was written for the Windows version of the trading system had to be replicated on the DOS version as well.... the traders had laptops that could not run Windows very well.
So, Marc had an idea..... why not write the Windows-based trading system in C, using the Windows API. And, for the DOS version, use the same API. This involved reimplementing the Windows API in a DOS library. This led to another product.... the Magma Extensible Window and Event Library... or MEWEL for short.
Next chapter.... MEWEL kicks Magma Systems into high gear....
©2005 Marc Adler - All Rights Reserved
Subscribe to:
Posts (Atom)
