Dr Bob Beaty

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 transferred 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, even though 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. He started working on an interesting matching problem with demand and merchants to make the sales team more efficient. The project was called Quantum Lead, and it used Big Data (Teradata) as well as Clojure, Ruby (JRuby) and a lot of fun, interesting, smart guys, to predict demand for deals, based on historical purchasing habits, current inventories, lead-time calculations for closing deals, and various purchasing models.

The project was a great success, and increased sales 23% in the first year it was used. The project was deployed globally, became a very successful sales tool, and went on to have a great run. When it got into the maintenance phase, Bob was approached by another group in Groupon to look at creating a streaming processing system using Storm to process all the incoming user click and activity events from all clients.

The Unified Click Stream started off gathering all the click events from all sources and creating a real-time A/B test dashboard. This would allow product managers far better access to their ongoing tests and would project a winner, with a confidence metric, based on the data. This same data opened up all manner of possibilities for the other groups in Groupon. Usage spread to groups that had nothing to do with A/B testing - just with a need for up-to-the-moment data on users, their activities, and collected statistics. It was a very successful project.

The atmosphere was changing, and after several years, and the loss of a very good manager, it was time to move on. Bob looked around and saw Centro, a digital ad company, looking to work on similar streaming problems, and decided to go there. The recruiter was a person Bob had worked with at Groupon, and was a great guy, but there were some high-level management struggles at the time, and about the only project that seemed to get going was one to gather all the ad data for the clients from the source - DoubleClick, YouTube, etc.

After a very short time there, one of Bob's co-workers went to a mortgage company, Guaranteed Rate to help them transition off a legacy monolithic app to services, and after a few months, reached out to Bob about building a Clojure-based service to show his manager what could be done in Functional Programming.

Bob joined his friend at Guaranteed Rate and helped build a Clojure ecosystem for services that spanned all different aspects of the business - underwriting, pricing, e-Consent, appraisals, and more. It was a fast-paced environment where the Business had a near endless list of requests. The team grew, split off, grew again, split again - all in a very healthy way.

There were impressive highlights in the string of successes: creating an APR calculation for all loan types, and conditions, creating an application package tool that would allow the user to be sent a legal application packet for digital signing in all 50 states, and more than 95% of the loans Guaranteed Rate wrote. This was a huge step forward in the automated processing of loans.

Yet nothing lasts forever, and after a few co-workers left, Bob looked again, and found The Climate Corporation whose approach to digital agriculture was something that really hit home with Bob. It was meant to be yet another chance to use Clojure, and everything seemed to align very nicely. After he joined, there was a real need for a team of high-level architects to help provide a more cohesive design of the systems, and Bob was asked to help with that. The Architecture Team started out with everyone being involved in most things, but after several months, it was time to focus, and Bob was asked to be the Architect for all the Clients for Climate: web, Android, and iOS.

There were many challenges associated with changing the culture of a start-up like Climate, to being an arm of a 145-year old enterprise like Bayer, and it had it's share of challenges, but after about a year, the web Client had been reimagined into a modular plug-in system where Client could build independent components that would interact only through a Javascript message bus, and enable far faster independent development and testing.

After a time, Bob realized that he really missed the creation aspect of the job, and so when an old co-worker reached out to ask if he was interested in helping clean-up and refocus a small shop called Vodori, he talked to the Founders, and was convinced this was a chance he didn't want to pass up.

Bob worked with the Founders to streamline the process part of the development cycle, he worked with the developers to add more documentation in support of the services, and assisted with a lot of technical documentation to make understanding the inner workings of the codebase much easier for the junior developers. It was a slow process, as there was a lot of inertia in the existing processes, and the kind of transformative change that had been discussed wasn't really being championed as Bob had hoped.

After about 6 months, it was clear that again, this was a situation where "Good people don't fit", and it was time to move on. There's always a sense of loss about what could have been, but it's wrong to assume that things will change when it's clear that they are content just the way they are.

As Bob was looking around, an old co-worker mentioned that the start-up he was involved with, Flexbase, needed some help, and would he consider joining in to help out? Bob had done the start-up business before, so he had a reasonable idea of what that was like, and the tech stack was something he'd never used, and seemed like a nice change.

This may last for 5 yrs, it may last for 5 months - that's the risk of a start-up. You can't predict what will happen. But for now, it's what he's working on, and maybe this will really turn into something, and even if it doesn't, it's a chance to learn an entirely new Cloud provider, and tech stack, and it's working with nice folks.