The Professional History of Dr Bob Beaty

Bob has been a professional programmer since the age of fourteen. At that time the Physics Department of Indiana University-Purdue University at Indianapolis, hired him to develop an assembly language program for their Nuclear Magnetic Resonance (NMR) research. After that, his programming jobs ranged from developing disk duplication software for the Radio Shack Color Computer, to scalable production schedule sheets written in Wang Wordprocessor scripting language, until he entered IUPUI in the Fall of 1979, and stopped programming for money and started doing it for grades. He transfered to Purdue at West Lafayette a year later because they had nicer computers and a better Electrical Engineering program.

When Bob graduated from Purdue University in 1988 with his Ph.D. in Electrical Engineering, he was the youngest Ph.D. graduate Purdue's School of Electrical Engineering had had. His thesis was on a new monolithic microwave source called a Contiguous Domain Oscillator, and included design, fabrication, and development of two-dimensional, transient, computer simulation programs for the new Gallium Arsenide (GaAs) device. While it might have taken him longer than he wanted it to, the thesis was very good work on the modeling of the physics of electron transport in GaAs in three-dimensions (two physical, and time).

Bob then went to Auburn University because of the work they were trying to establish in the field of III-V and II-VI semiconductor research. The match seemed to be perfect - the Electrical Engineering Department and Physics Department were trying to develop cooperative projects, and Bob was a natural link between the two fields because of his extensive work at Purdue in the fabrication and simulation of compound semiconductors.

After three years at Auburn, Bob had the feeling that he really wasn't fitting in. He had done some very good fundamental work in the field of stress in semiconductors, and development of ion-specific MOSFETs, but he didn't feel like writing papers as much as they wanted him to. The eventful day was after a particularly hard day, and a call came from Damon, the Best Man at his wedding, and his best friend of more than a decade.

The call quickly became about how hard their days were, and how, of course, they could do it better if they had their own company. "Yeah!" said Damon, "You bet!" said Bob. And before they could really think about it, they had agreed to quit their jobs and start a company based on telecommunications and computers. A few letters passed between them in the ensuing months, about what to do, etc. and within six months Bob was back in Indianapolis, and working for the start-up Port-to-Port Communications Corporation.

Bob was working his 12+ hours a day (5:10 am to 5:30-6:00 pm) when early in 1996 he decided that this wasn't all it was cracked up to be. Sure, he had been part of building Port-to-Port from nothing to over $1.2 million in 1995, but it was taking a toll on Bob that was not worth the compensation. Bob didn't like being the boss... worrying about payroll... hiring, firing, etc. So... he started looking for changes within Port-to-Port and seaking other alternatives. Port-to-Port didn't want to change, and that's what partnerships are all about - consensus, so Bob looked elsewhere.

Bob talked to Bret Young of the budding Architecture Group at First Chicago - NBD, and came up for an interview. For many months he worked as the NT person in the group. And then decided that he wanted to get back into management. Frankly, there just wasn't enough challenge to be found in the work he was assigned.

He lead Technical Architecture Group, and managed the resuable AKit - more than just a reuse library, AKit includes design philosophy, documentation standards, and applications.

The group flourished and did wonderful work. While at times it was hard, the work was wonderfully rewarding for Bob. But nothing good or bad lasts very long...

One day Marty Bronstein told Bob that he had to disband the group because the group held some of the best programming talent in the Capital Markets Systems staff, and while they would probably come to regret the decision in the future, there might not be a future if certain projects didn't get completed. And so the days of wine and roses came to an end.

Bob then filled in doing Year 2000 work until the BankOne merger finalized, at which time he was put into a rag-tag group of assorted talents and given the responsibilities of Research and Development for Commercial Banking. This was certainly up his alley from the work he did on Java/CORBA as part of this Technical Architecture Group Leadership, and the idea was pleasing.

Unfortunately, the reality did not live up to the idea.

And so, after a time, Bob was approached by Joel Herm to help build a system for Commercial Card Services - OneCard. At the time, Commercial Card Services (CCS) in Commercial Banking was dealing with an unresponsive external vendor of their card maintenance application. The web version wasn't exceptional, and they were looking for an alternative. We provided them with one.

OneCard Started in early 1999 and by September of 1999 Bob had built over 250,000 lines of debugged Java code that was the majority of the back-end. He had also built the database, and worked with the Exodus folks to set up the production hardware and get the necessary leased lines working. He was just waiting for the final test data from Total Systems to finish off his part in the project.

And then it happened again...

The users decided that they didn't have enough money to continue this project, eventhough it was estimated that it would save them $10 million in less than 5 years, so they cancelled it. And everyone had to move on.

After this, Bob and Joel tried to stay together and gravitated towards a project that Joel had been working on for almost a year - DealTracker. It is a web-based deal-tracking system that allows front-line people in many areas of Commercial Banking to track the deals they are working on, and by the tracking, get a better idea as to what they have done, and what they are doing.

Things were going well until the Summer of 2000 when once again, upper management decided that this was a system they could do without, and cancelled it.

After a time, Bob was offered the choice of taking a package worth half a year's salary or getting another position in the Bank... needless to say, the package won.

Bob spent the first several months of 2001 looking for a really great position - something that reminded him of the best days at Port-to-Port and First Chicago. It was hard, as the job market had shrunk quite a bit, but Bob kept at it. Finally, in June, Bob met the folks at UBS O'Connor, and they seemed to be just what he was looking for - great people with interesting projects, but most of all, great people.

Things at O'Connor started out great. Bob was working with a group of five really talented guys. He and Matt Parker were working on the client-side and Jeremy Mayes, Mike Elmore, Mike Osowski, and a part-time consultant were working on the server-side of a center-state risk platform called MarketMash. It was very exciting, and there was a lot of progress in a very short time making the Team feel that they were really part of something special. But nothing good or bad lasts forever, and the bubble burst and business had to let go all but Jeremy and Bob.

For the next several years Bob and Jeremy handled much of the back-end development for the single-manager funds in O'Connor. It was lean times, but it led to some of the most incredible work Bob had done. Analytics Engines, MarketData servers, ticker plants, all needed to be written for one reason or another. It still represents a fantastic portfolio for Bob, but things changed again and Jeremy left for another position and the fun went out of the position for Bob.

Bob then took a position at Chicago Trading Company in the new Risk Analytics Group. They were starting a new group to try and look at the global risk picture of the organization. Since Bob's work at O'Connor was right along these lines, it made a lot of sense for everyone involved.

Rather than work on the engine that drove the numbers, as he had at O'Connor, Bob started work on the presentation system. This was a nice change, and the initial goals were to get the global risk numbers into a web system with a "Google Finance" style of presentation. With the nice web interface - including zoom, pan, and active refreshing of the data without refreshing the page. This lead to an AJAX/Tomcat system using the Google Visualization toolkit with a ton of JavaScript on the client side to manage the application.

This continued to the point that the application was really a suite of pages - each one a different view into the global risk picture. The data was constantly being collected, and a vast data warehouse was started. The majority of the displayed data was held in an H2 in-memory database approximately 100GB in size. The capabilities of this system are impressive and it's found many uses outside those initially planned.

Things were going well, but the fit wasn't exactly what Bob was looking for, and since his days at Port-to-Port Bob has believed the adage: Sometimes, good people don't fit., and deep-down, Bob knew he had to leave. Fortunately, another trading company in Chicago - also started by a group from the old O'Connor, PEAK6 was looking for good people, and Bob decided to head there.

Initially, Bob was to work on a risk system for the new next-generation trader tools that were being put together. The initial set of tools was built by David, Bob's new manager at PEAK6, and a recent partner at the firm. But when he arrived, Bob found out that the project that needed his attention most were the feeds. In the previous two weeks, there had been outages on seven of the ten days. With his background in the feeds at O'Connor, they asked Bob to step in and see what he could do.

Bob starting working in the Messaging Team, and quickly realized that what was needed was not a simple updating of the existing code, but a complete re-write. The entire system needed to be re-imagined from a different perspective - one where multiple threads ran full-speed with lockless data structures, and the differences between the exchange feeds were handled in simple, modular codecs, and not in completely separate systems.

This work was a great success, but when it came time to integrate it with the existing systems, none were really ready to handle the feed. This was not completely unexpected, but it did lead to a very interesting turn of events. Rather than incorporate this new DataBus into an existing project, Bob would be tasked with another re-write - this being the pricing server that generated all the greeks and implied vols for the different systems in the firm. The thought was that as the primary client of the new feeds, this would be the code that could take greatest advantage of the new feed's potential.

It's interesting how history repeats itself, as Bob was working on a similar project back at O'Connor - MarketMash. But this time the goal here would be far greater than this previous effort. For this pricing server, the goal would be to integrate the ticker plants into the server - making it even lower latency, include a what if scenario capability, add in a demand-driven update scheme so the fastest clients got the latest data, and the slow clients didn't overload the system or compromise the data.

The new pricing server went to production with a record-low number of issues for an infrastructural component of it's size and scope. Things went very well for the deployment, but at the same time, several organizational changes were in the offing, some promises weren't kept, and PEAK6 and Bob agreed it was a good thing to part ways. As Bob's always known Some times good people don't fit.

While he was looking for a new position, Bob did quite a bit of Open Source work and placed it on GitHub. This has been a long-held goal of his - to create some of the tools and libraries that end up getting reinvented every time he goes into a new position. He also was introduced to some guys at a very nice little startup, and wanted to help them out with a little something that he'd done previously - again on GitHub.

In the end, however, it was full-time work that pulled him away and was able to find a very interesting position outside Finance at Groupon. As one of the largest Ruby/Rails shops in the nation, it gave him a chance to learn a new language as well as tackle some very interesting problems. Currently, he's working on an interesting matching problem with demand and merchants to make the sales team more efficient. It's working with big data (Teradata) as well as Clojure, Ruby (JRuby) and a lot of fun, interesting, smart guys. Great fun.