Andrew's Work

Below is a brief summary of my work. I've been fortunate to be involved in some pretty amazing stuff!

We are currently moving to Colorado, and I am on the lookout for new opportunities. If you are doing something challenging in the Denver/Boulder area that you think I could contribute to, reach out to me via LinkedIn!

2004-2015: Kiva Systems, an Amazon.com Company


I joined Kiva Systems as the first full-time software engineer back in 2004, shortly after Mick Mountz, founder and CEO, landed our first round of funding. Mick brought in Pete Wurman and Raff D'Andrea to start the company, and Raff (not-so-coincidentally my old college professor) brought me in to help them get the software parts of their slightly loopy-sounding idea off the ground.

Over these past 11 years, I have witnessed and enjoyed the benefits of our success, and worked hard alongside my fellow Kivans to make our exponential growth hopes a reality. I had the opportunity to be an integral part of our acquisition by Amazon.com for $775 million, which turned out to be a great fit for us. Over the years, I have done a little (and sometimes a lot) of everything, pushing through endless challenges and celebrating all the successes. In the last few years, I have had the pleasure of being the tech lead for our ever-growing production software group, currently an organization of over 160 people.

About Kiva Systems

What does Kiva do? Kiva invented a completely new paradigm for how to run a warehouse. We unleash 1000's of semi-autonomous robots in large (think 20+ acre) warehouses, and make them do all the grunt work of moving stuff around.

How? Our robots lift and move tens of thousands of portable shelves around the warehouse, fetching and storing them in different locations, and bringing them to dedicated work areas around the periphery. Along the periphery of the robot work area, people can interact with the shelves. This lets us run a warehouse like a giant random-access cache, with processing points all around the periphery of the building.

It works like this: Imagine going into a grocery store (or a Costco, etc.) and instead of browsing the aisles, you head straight for the checkout. Moments later, the grocery store shelves start showing up with the products you need! Little orange robots whisk them over and put them away again when you are done. This is happening concurrently at all the checkouts.

In the checkout area, a touchscreen shows you where the products are that you need, and directs you to scan them and place them into bags. There is no need to wander the store aisles - everything you need is presented right in front of you.

Maybe two stations down (or more likely at the back of the store) you can also see an employee restocking the shelves from a pallet - completing the same process but in reverse. The system is choosing the shelves, the robots are bringing them over, and the employee is placing the items on the shelves.

Now, if you are like me, you probably enjoy browsing through the grocery store shelves. So, this solution isn't meant for the consumer environment (at least not yet). Kiva actually serves a much bigger market - the hundreds of thousands of warehouses that make world commerce work.

This approach works well - REALLY well. The ROI is great - robots are not nearly as expensive or valuable as people. Human productivity goes way up. Less walking, a nice stationary work environment, quiet robots provide a much less hostile environment than traditional warehouses offer. I learned firsthand that people love having their own work area instead of bumping elbows on a stretch of conveyor where the slowest employee dictates the rate (and earnings) of the entire line!

Because the system is a generic cache, it is self-reconfiguring, automatically putting the Easter candy up-front in the days leading up to the holiday, and moving it to the recesses of the warehouse in the days or weeks following the holiday. It's pretty awesome.

My Role

Being with the company for so long, I've done a bit of everything. Early on, I wrote a big chunk of our first prototype system, choosing our technology stack. I also set up our company IT/infrastructure, which we were careful to do on a shoestring budget. We were scrappy - good with our capital, which was really important as we rushed to create a prototype and garner our first customer.

Within the first few months, we cranked out a proof-of-concept system. I put together a stack of C/C++ code, mysql, and some custom messaging infrastructure, and then dug into implementing the 'meat' of our system - logic that monitors and controls the robots, the user work areas/stations, the inventory tracking, and the first set of algorithms that put them to use. This prototype system was critical - we learned at lot, and at all stages we had more and more proof-of-concept that we could regularly show to prospective customers. We even performed "road trips" to a prospective customer site, showing them that it could work for them. Everything and anything we could do to make them see exactly how the solution would work in their environment.

Needless to say, this was a big success. We landed two PAYING pilot contracts from demonstrations of our prototype system. With checks in hand, validating our business model in the best way possible, we went for our next stage of funding and build our first production-worthy hardware and software.

At this point, we decided to switch from C++ to Java for anything server-side and at the stations. Java was maturing rapidly (I think Java 1.4 was out) and it turned out that we didn't need the speed of C++ - better to capitalize on the larger pool of talent working in Java, and the abundance of open source infrastructure that we could leverage.

At that point, we re-wrote our infrastructure in Java. Looking back now, I realize that what we wrote was a lot like the Akka Actor model and supporting infrastructure, but at the time that didn't exist. Our implementation wasn't as generic as Akka (or clean, or complete) but it worked really well for what we needed to do, which was to divide up system responsibilities among different components, and route information and decisions between them. This infrastructure served us well through the years ahead!

During this time period, things moved insanely quickly. We re-wrote our stack with production-level features and quality. We designed new algorithms to run at production scale. Some of this was code optimization for scalability - for example, switching from Dijkstra to A* for robot path search. But other work was really invention of the algorithms we use today, for example figuring out the best place to store shelves based on predicted future need, etc.

Getting our first code into production was a challenging 'birthing' process. Endless hours spent in freezing-cold and roasting-hot warehouse environments in a coding frenzy, continuously learning and adapting the software to meet the needs of a true production system. We lived it and learned from it. Looking back, this grueling hands-on experience was a gift that served me well in the years ahead. By the end of the pilots, I finally understood everything that we were trying to accomplish at a very personal, intuitive level.

Pilot programs led to our first true production contracts. We were on a roll! The demand for new features, new innovation continued to grow, and we kept accelerating. In the years ahead, we added some incredible new features to our core design. We started putting more than just inventory on our shelves - we also started moving around the pallets, customer shipment boxes, etc. We focused a lot on generalization and runtime-configurability that could allow us to meet the needs of a much larger percentage of the overall logistics market.

For example, I remember adding a neat feature we called 'sequential pick' - we could control the exact sequence that items would arrive at the station, allowing us to do neat things like fill totes in the order in which they are needed for an assembly process or for later unpacking. Interesting features like this presented really interesting data flow and state management challenges.

Around that time, I also had another stab at our movement subsystem implementation - all the logic that controls how our robots move around the warehouse without running into each other. I led that project - our biggest ever at that time, and I'm proud of the system we produced.

The housing market contraction in 2008 was a little scary, but we did well in sheltering through the storm. We landed some key contracts, and kept our eye on the ball. Coming out of the recession, we were starting to think about our plans for going public. It's at this time that Amazon approached us, and made us an offer.

In 2012, we were acquired by Amazon.com for $775M, the start of a new (and equally exciting) chapter in our history.

Since then the pace has kept up. Following our acquisition, I worked on revamping our entire production software stack to align more ideally with Amazon's needs, serving as the principal engineer for our (now pretty massive) software dev group. It has been a great experience, and Kiva turned out to be a natural fit with Amazon.

2000-2004: Interdimensions, Inc.

Prior to joining Kiva, I did some other fun stuff. I spent 4 years working for a Boston-based company called Interdimensions. We were a boutique software firm, capitalizing on the web revolution in interesting and novel ways. In those years, we built a lot of B2B and a few B2C systems and solutions. But, by 2004 our market finally fizzled out - companies were finally able to take on the kinds of projects we did internally, at a much reduced price point.

I was mostly a 'software architect', which in our software consulting company was the person that drove the technology work that was being done. We were small, so driving the tech just as often meant doing the work, and this is where I really developed a passion and talent for writing software. We worked on a lot of really interesting projects over those years. Here are a few of my favorites:

Imagination & Ford Fusion: I led the design and development of a C++ based PocketPC app for a London-based client under a tight and demanding deadline. The software introduced Ford dealers in the U.K. to the new Ford Fusion vehicle by guiding them through a tour of the countryside in the new vehicle on a scavenger hunt. The application provided the car dealers with driving directions, key facts about the new vehicle, and quizzed them on their knowledge of the new Fusion. “Winners” of the guided tour could be quickly calculated and awards given, based on number of questions they answered correctly and their completion times. The system was a resounding success.

Imagination & Samsung: I contributed to the design and development of a unique Palm-based snowball fight game showcased by Samsung at the 2002 Winter Olympics. I primarily developed the server software to manage the gaming interaction and scoring between eight PalmOS gaming devices, all attached via serial port to a central server. The resulting gaming environment operated flawlessly and created a positive, engaging experience for visitors at the 2002 Winter Olympics.

The M&A Group: I designed and directed the development and deployment of a $3M Flash-based website to be used by a collection of the world’s most powerful CEOs, dubbed ‘For CEOs Only.’ Utilized a rich and highly flexible multiple-tiered architecture and XML to deliver dynamic content through a Flash interface. Server-side software was designed and developed using proprietary C++ technologies on the Sun Solaris operating system.

Schlumberger Simagine Competition: This was more of a business-development project; I constructed a distributed transaction system in which a person’s trusted personal web services (e.g. a banking or medical web transaction service) could initiate a high-bandwidth digitally signed transaction with another web service on behalf of an individual, but only if first approved and signed by a person’s encryption key stored on their cellphone or personal computer. In an era before cellphone-based transactions, we showed that cellphones (and their built-in SIM cards) could be used to securely approve and digitally sign server-to-server transactions without having to push the to-be-signed documents through the cellphone devices themselves.

EF Education and Englishtown.com: I designed and directed the development of an online Java and Javascript-based testing engine used by EF Education to prep international exchange students for their travel to the US. The testing engine proctored tests, collected results, and even included a suite of online test authoring tools used by EF to create and update the online tests.

Education


Ok, I don't like to admit it, but I wasn't actually a CS major in college. But as an Electrical Engineer, I did study very computer-oriented topics, and I did write a good amount of software - especially under my Master of Engineering projects. While at school, I worked on our RoboCup robots with Prof. Raff D'Andrea (one of the three Kiva company founders) as my main Master of Engineering project. I also worked on developing videoconferencing software for my information theory professor. Over the summers, I also worked on using neural nets to interpret EKGs for my undergraduate adviser.

1998–1999 Cornell University, College of Engineering, Ithaca, NY
  • Master of Engineering, Electrical Engineering, with System Engineering Option.
  • Focus in Communication Systems, Biomedical Signal Processing, and Information Theory.
  • World Champions, 1999 RoboCup Autonomous Robotic Soccer Competition.

1994–1998 Cornell University, College of Engineering, Ithaca, NY
  • Bachelor of Science, Electrical Engineering.
  • Focus in Communication Systems and Digital Signal Processing.

Patents, Etc.


I'm on some pretty cool patents at Kiva. We were careful with our cash, so we just patented the most important stuff. I think I am a co-inventor on around 14 published patents at the moment. You can find them at the USPTO website, but they're in patent-ese, so they probably aren't much fun to read. Mostly they deal with a lot of our key concepts around system behaviors and our robot motion control logic.

We've developed a lot of cool technology over the years. Much of it I can't talk about, but I can say that I've seen and worked on a lot of neat problems.