It is generally agreed on this Wilmott forum that 60% of the work of a quant (developer) is spent on programming/software development.Many threads discuss what the ideal profile of a quant is, for example, background in topic A, B, C from university X, Y, Z etc.I was just wondering if software design or engineering skills are important? Or do people learn s/w on the job?Is software easy? What's the hard part?

QuoteOriginally posted by: CuchulainnI was just wondering if software design or engineering skills are important? Or do people learn s/w on the job?i doubt it. sw design becomes important in large scale projects. why would quants b doing this? it's sw developer's job. i could see quants designing/optimizing algorithms, but that has nothing to do with sw design per se. it should b left to professionals who do it everyday.

Quote it's sw developer's job. i could see quants designing/optimizing algorithms, but that has nothing to do with sw design per se. it should b left to professionals who do it everyday.Why do I sometime see on the board about needing templates and multithreading skills? I would think it would make more sense for the quant to get a crude working implementation of a model and have a SW developer make it useable.

QuoteOriginally posted by: jcrewWhy do I sometime see on the board about needing templates and multithreading skills? I would think it would make more sense for the quant to get a crude working implementation of a model and have a SW developer make it useable.templates r simply useful, and sometimes make code compact and beautiful when applied smartly in generic programming style. multithreading is important for those who construct parallel algorithms. however, i think that the main reason why multithreading is important is because IBs r lagging in use of app servers and Java. in many cases thread programming is simply waste of resources. they code thread pooling manually, writing tons of custom code. these things r done well (often better) by app servers. once java replaces C++ for thread programming, multi-threading skills wont b needed as much, and will b niche skills like they r in the rest of the world. just wait and see

Threads are here to stay.Modern CPUs have multiple cores, if you write single threaded s/w it will run anything from twice as slow to eight times.When you're dealing with the outside world, like servers or price feeds, then without threads your system will run terribly slowly.

knowing something about finance would help. Not bull shitting people and being honest would also help. Not trying to flog them any rubbish job and trying to convince them that this is the best they can offer is also something you should try and avoid. Getting to know as much about a recuriting firm is also good as well so when an applicant ask a question regaring the firm you have an answer. and not assuming anything about an applicant is also god..I could go on, but I think, as ppauper would say, we should discuss this over dinner...?? without ppauper present ofc ourse

QuoteOriginally posted by: jcrewQuote it's sw developer's job. i could see quants designing/optimizing algorithms, but that has nothing to do with sw design per se. it should b left to professionals who do it everyday.I would think it would make more sense for the quant to get a crude working implementation of a model and have a SW developer make it useable.This is one possible scenario. Are there folk who design and implement a system (in one and the same person)?So, my questions now would be:- what's a crude algorithm? hopefuly the quant has left out no vital information for the IT guy. Danger of falling between 2 stools.- does the s/w developer need to understand the algorithm to get it really working?- the hard part is algorithmic design, coding is (relatively) easy, when you know what you are doing, yes?I am limiting my questions to serial programs, not parallel/MT ones because then the rules are (completely) differentQuoteWhy do I sometime see on the board about needing templates and multithreading skills?You're kidding me, of course (hint: google speedup)One answer isQuoteModern CPUs have multiple cores, if you write single threaded s/w it will run anything from twice as slow to eight times.

QuoteJavaBean: once java replaces C++ for thread programming, multi-threading skills wont b needed as much, and will b niche skills like they r in the rest of the world. just wait and seeAmusing that C++ folk never say "once C++ replaces A, B, C ..". What's up with the Java guys? Bad generics, is that it?Each language has its uses. It's a non-issue.

QuoteOriginally posted by: CuchulainnAmusing that C++ folk never say "once C++ replaces A, B, C ..". What's up with the Java guys? Bad generics, is that it?i see it happening on unix space. there's less and less C++ left in business applications. in a place i work now, they pretty much stopped doing any new devl in C++ altogether. economically it doesnt make a sense.generics in Java r bad, it's true

Here are my personal experiences:1. Unix became popular in the late 80's / early 90's when it ousted VAX/VMS. In the late 90's it started to decline mainly because of Windows and possibly linux. Besides, some UNIX developers have moved on.2. In the late 90's/ early 21st century Java became very popular and it replaced C++ for some applications. Since a few years C++ has undergone a revival and this can be felt in the market (across a whole spectrum of domains). In fact, I think C++ will live forever, at last for the forseeable future.3. C++ is an evolving language and the other languages are playing catchup (e.g. generics). A good C++ programmer can learn any other language but not vice versa. It is a well-designed language and a hard task master4. Last but not least, many of the planet's critical applications are in C++. Employers want to see it on your CV. People want courses in C++, everywhere, from uni folk to business organisations.5. C++ has a future, Java has a future but for different communities. C# has a future as well.6. Hypotheses: it takes 15 years before technology becomes accepted and even longer before its end-of-life.Quoteeconomically it doesnt make a sense.What's the alternative?////Disclaimer: I could be wrong because prediction is so difficult (especially the future )End of rant

QuoteOriginally posted by: CuchulainnQuoteeconomically it doesnt make a sense.What's the alternative?Java and J2EE if the servers are Unix. look, Unix shops will move on to Linux, if it's economically reasonable. like, in our project I strongly recommended to move to Linus/x86, because it's cheaper to build highly scalable solutions.in my everyday life I do some multi-threading, but not a lot, because 90% of that is done well by app servers. the same comes to garbage collection and a lot of memory management. it's cheaper to set up and buy Linux/x86 solution than build highly sophisticated software. a lot of things are simpler in Java, and your programmers can concentrate on business rather than comp science. we're not in software business, we're in money making business. we should think of money not semaphores i'm not saying that C++ is out, i'm just saying that it's being pushed out of app programming space for good reasons. wall street's going to catch up with the rest of the world, there's no doubt about that. app servers will come. consider something like BEA WebLogic. it's a big application, and it's written almost entirely in java. those programmers r good. i dont have to deal with all this thread-pooling and stuff anymore, they took care of it. ok, i had to write a little piece in Sparc asm a few weeks ago, it was refreshing, but i explained my client that it was small isolated component and that it wont happen again

QuoteOriginally posted by: jawabean[in my everyday life I do some multi-threading, but not a lot, because 90% of that is done well by app servers. the same comes to garbage collection and a lot of memory management.Most app servers just will not work for the type of trading system work that one finds in high frequency finance. There is however a cottage industry which is developing in what is essentially writing financial app servers, and a lot of the work in that is in Java.Quote wall street's going to catch up with the rest of the world, there's no doubt about that. app servers will come.Yes they will but they are likely to be special coded financial app servers. The problem with non-finance app servers is that they can tolerate latenecies that are unacceptable in Wall Street. In the high frequency stuff, the server has to be able to take continous incoming information, process it, and then execute trades within a few tens of milliseconds. The throughput could be something on the order of 1 TB of data each day that has to be processed. Also there is the reliability issue, if something goes wrong, you want to have the programmers on hand to fix the problem live.There's also the fact that money is not a major constraint. If a bank feels that they need to write their own app server, they have the money to hire the programmers to do it.

Twofish has a point, that the price you pay for App servers doing everything for you is that they can make decisions that you really don't like.Also they typically lack the necessary interfaces to do anything about it, or for proprietary reasons hide them.This is an architectural issue, and one that affects Java just as much. Java takes control of a lot of resources, especially memory.Java can make life a lot easier, but is a complete pain in the arse if if makes the wrong decisions.The Java/App server problems are often of the kind that merely buying a much faster computers won't solve the problem Lock and frag issues are simetimes combinatorial explosions, which a computer that's "merely" 3 times as fast simply does not dent.J/AS systems are perfectly fine in relatively low speed environments, or ones where the occasional stale price doesn't matter all that much.

QuoteOriginally posted by: twofishYes they will but they are likely to be special coded financial app servers. The problem with non-finance app servers is that they can tolerate latenecies that are unacceptable in Wall Street.trading is a special case. i dont have experience in this field, but i would imagine that it's in the realm of real-time systems. in RT world both Java and .NET have issues. it's not just the latency, Java now is (almost) as fast as C/C++, and is definitely faster than any C/C++ hw/sw configuration of 10 years ago. the issue is that latencies r unpredictable, it actually is OS problem too. there r special RT OSs, maybe that's what u need.on the other hand, if it's not RT-type system, then Java app servers r not much slower than C++, and u can always buy new hardware if u really need a special financial app server, then u can take Geronimo and jBoss. these r highly modularized systems. u can assemble your own app server from parts or replace/customize stock components to meet your needs. it saves a lot of time, you can lose performance here and there, but in total it's economically more productive. you wont need super-duper programmers too, just a couple of them to maintain the core, no more low-level multi-threading quizes on interviews. developers will b like commodities with standardized skills, and in ample supply, cheap.