Ongoing full-time employment since May 2016
ASV is a data science company that helps auto dealers order and manage the cars on their lots more efficiently. I joined ASV as the first web engineer back in 2016. At that time, ASV had no modern web apps, their main software that ordered billions of dollars per year worth of cars was running in Excel and written in VBA, and there was no cohesive design or branding. I've helped ASV migrate to web apps running on a Django-Angular stack, consolidate all of our code into python, host our applications on AWS, automate countless previously hand-done tasks, unite our software with a cohesive design, and prioritize user experience. Now we are looking to expand our software to new car manufacturers and build new products that will further improve the efficiency of the auto industry.
AutoSalesVelocity (ASV) started as a small pilot project back in 2005 when the four co-founders hatched a plan to innovate the auto industry. The hypothesis they were testing was simple—could they use data to help auto dealers manage their dealerships more efficiently? The MVP software that helped them test their theory was a shared Excel spreadsheet. The benefit of using data to drive business decisions at car dealerships was immediately obvious, even with some simple Excel magic, and the pilot program didn't stay small for long. AutoSalesVelocity grew quickly by word-of-mouth, and with it, the software evolved organically. The story of AutoSalesVelocity has been one of engineering struggling to keep up with the growth of the company. This meant that often over the first decade of ASV's existence, the small things that build brand and maintainable software were continuously pushed off into the future—there simply wasn't enough engineer hours to keep up. And like any agile company growing faster than it can keep up with, there was a lot of legacy code that was hard to debug, update, and piece together. ASV could have taken funding to keep up with growth, but they chose to go against the grain and bootstrap the company. To this day, ASV is a profitable company that has never taken investment.
When I took my job at ASV, I was essentially the first web engineer the company had ever hired (they hired me and another guy at the same time, but he left after a year). I had several job offers lined up, a few of them with budding startups with lots of funding. I chose to go with ASV because I like to think that I saw the potential most software engineers overlooked. I've noticed that in the software engineering community there is often a culture of engineers only wanting to work on the latest, greatest technology. They do it because they want the experience to put on their resume for their next job and because they are the type of people who like to stay on the cutting-edge. I'm different in this regard. The reason I love software is because it give me the power to solve problems. Above all else, I love solving problems—the harder the better.
When I showed the ASV job listing and promotional website to my friends as I was applying, every single one of them said they wouldn't touch ASV with a stick. The software looked hacky, and a lot of it was written in VBA that ran in Excel. The design was out-dated. And how could they ever put AutoSalesVelocity on their resume with that logo?
Many of the people I know and trust in the software community told me to steer clear of AutoSalesVelocity, but where they saw long days unraveling legacy code, an insurmountable mountain of work just to get everything "caught up," and an unsightly job section at the top of their resume, I saw a challenging problem to solve. And one that was clearly worth a lot of value, but that most engineers (even good ones) weren't willing to take on.
Most of my work from 2016-2018 was migrating old software to modern web apps while upgrading the aesthetic design and UX. I wrote the majority of the software that replaced our main app, which is responsible for most of our revenue and orders almost 10% of all Ford vehicles in the USA. I've led the migration of several static web apps and iPhone apps to progressive web apps written in Django and Angular. And finally, I've redesigned the branding and promotional material for the company, including, but not limited to, the logo, promotional website, and business cards.
The original ASV logo created by the founders lasted nearly 15 years and grew the tech company to twelve employees. That's a pretty good run, but in 2019 it was definitely time to update the look and feel of our brand. Below is an image of the original logo.
As you can see, the old logo used an out-dated Helvetica font and included text that was usually far too small to read.
This is the logo I designed in 2019 to replace the original. We knew that we didn't want to do a total overhaul of the logo and make it unrecognizable to existing customers. So instead of coming up with a clever icon that combined elements of data and cars, I tried to stay close to the original design and update it rather than redo it.
Since the "AutoSalesVelocity" text below the "ASV" in the logo was typically too small to be readable, I replaced that with a line. The founders originally designed the logo with italic text to embody the "velocity" in AutoSalesVelocity. To give the new logo the same effect, I tapered the ends of the line to make it lean forward. I experimented with changing the font to something construction-industrial and bold, but ultimately decided to kept the font as a serif. My final font choice was Playfiar Display, which I hope will give the brand a more modern and classic-industrial feel. Finally, we needed something that enclosed the type to make the logo a more uniform and symmetrical shape. A square was the obvious choice and also gives us the added benefit of being able to easily alter our logo to match various color schemes.
Like our logo, the ASV promotional website had a good run, but it needed a makeover. One of the funny things we noticed about the old site (and only after years of it being live) is that the image of a car driving that appears front-and-center at the top of the home page has the car driving on the wrong side of the road (we only do business in North America right now).
Armed with our new logo, I designed our promotional site to match. I kept our colors the same as they've always been—blue and orange (go Broncos!)— while updating the fonts to match and pair with the Playfair Display used in our logo.
__insert image of asset guid__
One of my favorite upgrades to our new site are the illustrations we had custom made by an artist. I like to think of myself as someone who is creative and has artistic ideas, but that doesn't have the skills to bring what I see in my head to life. The illustrator I found on upwork was amazing; she was able to take my crappy pencil sketches of how I envisioned each illustration and bring them to life almost exactly how I had imagined them.
__insert image of illustrations__
Without further ado, here is the old website:
And Here is the new website:
As I mentioned in the company history section, ASV started off using an Excel workbook to do the data analysis for ordering cars. Over time, this Excel workbook grew organically with needs. The founder (my boss) who is in charge of engineering slowly added features to improve efficiency and over the course of a decade he used VBA to build the craziest Excel workbook I've ever seen. It had multiple layers of caching, sqlite databases, it used dropbox as a shared database, etc.
When I was hired, ASV knew that our Ordering Terminal needed to be rebuilt. The app was actually a shared workbook and the employees who used it to order billions of dollars worth of cars per year had to save constantly because of random freezes and crashes. To say that it was redefining the limits of what VBA and Excel could do would be an understatement. I was tasked with replacing this app, which led to a lot of internal debate about how to do it.
For starters, there were so many features built into the Ordering Terminal. And each of our seven Inventory Managers that used the app had special features built for them over the years that the others didn't know about. We knew from the start that matching all of the features before even a beta launch was going to be hard. We couldn't launch without feature-matching, the Inventory Managers were already ordering as many cars as they could reasonably do in a week and any slowdowns caused by cutting useful features would have been a huge hindrance. Furthermore, the team was used to working in Excel and didn't want that to change. I tried to convince them that we should rebuild the app on the web, but they didn't want to give up some of the features that would be hard or impossible to replicate on a website.
The Inventory Managers like to have a worksheet of every car they have ever ordered with dozens of fields about that car. For the co-founders who have been ordering a long time, this is nearly 100k rows and ~50 fields. They like to be able to scroll through this history, filter, sort, etc. and have everything be instant. As an engineering team, we thought it was going to be difficult to provide a similar experience in the browser. The other thing the Inventory Managers like is the ability to leverage Excel and create ad-hoc formulas on the fly to do analysis that isn't baked into the app. That would also have been hard to implement in a browser.
After doing some research we decided that there were two viable options. First, we could build the app as a desktop application. But that seemed like a lot of work to make feature-compatible with excel sort, filter, ad-hoc formulas, etc. Not to mention the fact that none of our engineers had experience making a desktop application like this. After some research, we found a python library called Pyxll that's a wrapper over Excel. Essentially, it allows you to write python code and open up your python application in Excel while leveraging all of the Excel features via an API. We decided that if we used python to build the app in Excel as a psuedo-front end browser, we could still write REST APIs to serve the data. This is the solution we went with and it's actually worked out well for us.
Is it hacky? Yes. Is it a beautiful tech solution? No. When I told my friends about what I was working on, they would often feel sorry for me and offer to buy me a beer. This is actually one of the projects I'm most proud of. Sure, it's not cutting-edge technology nor is it written in a way that any other developer could ever easily jump in and contribute to. But what it lacks in sexiness it makes up for in utility. The application is a huge improvement on the VBA/Dropbox model from the previous model. And most importantly, all of the Inventory Managers who use it all day every day love it. It's exactly what they wanted and needed. And because everything is written in python and the Excel Pyxll app can interact with our Django REST APIs like a browser, we've been able to easily and quickly add dozens of features the Inventory Managers have been asking for for years. Most engineers work on pretty and sexy software that few people ever use—often the code never even gets deployed. While our Pyxll Excel app is neither pretty nor sexy, it is incredibly effective and achieved all of the business goals we laid out when we started the journey of rebuilding this app.
The other reason I'm proud of this app is because I basically had to make a framework to efficiently build these applications in Excel. Pyxll provides us with an API to control Excel, but it doesn't have any tools to help you build your applications. Using what I know about web frameworks, I created a framework in Python for Excel that other developers have actually complimented me on. I also had to build this application with no help. Go search the internet for Python/Pyxll questions. There is nothing on Stack Overflow, Quora, etc. What we decided to do (and pulled off) was so crazy, I'm sure few, if any, people have ever done something similar. The Pyxll API to Excel is also pretty terrible and has about 3 short paragraphs of documentation. When I hit bugs and errors, I had to go read the source code. There was no pasting the error message in Google and finding dozens of questions about the same error with well-explained answers.
Finally, in order to get our Ordering Terminal super fast to maximize Inventory Manager productivity, we've had to dream up some fairly creative (though sometimes hacky) solutions. For example, when you're using Python/Pyxll to add styling to cells in Excel, each call to Excel slows down the application. Our Ordering Terminal is capable of showing hundreds of tables, reports, etc. that all need to come up in milliseconds. In order to reach this efficiency, we couldn't have Excel restyle all of the cells, one-by-one, each time a user clicked a button to see a new report. That literally took seconds. So we made a hidden worksheet that styles fake reports and then we copy and paste the styles in one Excel call for ~1000x performance enhancement. There are also several layers of caching the application leverages. We track every Ford vehicle in the USA, which is a lot of data. The reports consumed in the Ordering Terminal use most of this data, and years worth of it. We have systems that are constantly caching data from our database to Redis. Then we have desktop applications that run on each Inventory Manager's computer that caches that data on their local machine and updates it when there is new data. And finally, when the Ordering Terminal is open we are constantly checking the cache on their hard drives and putting that into memory in Python to make it even faster. These are just a few of the crazy things we've had to do to make the Ordering Terminal fast and feature-rich.
It's nice to work in frameworks and well-supported, new technology. I won't deny that there were days during the year that I built the Ordering Terminal in Pyxll that I wondered what I was doing with my life. My friends would talk about the cool projects they were working on in the latest technologies and the ways they were working to innovate the world and I would get a little jealous. But at the end of the day, I knew that what I was building would be useful, and that kept me going. Looking back, almost all of the projects my friends were working on were either never launched or have been deprecated for various reasons. So I'm proud that the Ordering Terminal I built is used and loved by our team every day and orders billions of dollars worth of cars per year. It's pretty cool to get to "own" a project like that, even if the technology it was built in isn't what I would have chosen as an engineer.
I've had the opportunity to build a lot of software while working at ASV. And I get to deploy code on a daily basis. While the Ordering Terminal was a large project that I still make improvements to on a regular basis, most of my time working at ASV has been spent building progressive web apps with Angular and Django. We have software that we license to Mazda that I built in Angular. We have several internal applications that help us manage our data collection and data formatting that are all built with Angular/Django. I've helped deploy our site onto a kubernetes cluster hosted on AWS. I've written code that collects and compiles gigabytes worth of data every month. I've designed business cards. I've hired engineers. And I've built dozens of small widgets in our apps that have improved the efficiency of our company by eliminating previously hand-done tasks.
My first three years working at ASV has been a saga of updating all of the software so that it's on a single stack, in the cloud, and written in maintainable, documented, and tested code. Now that we have officially replaced all of our legacy code and automated our hand-done tasks, we are positioned to be able to quickly build software and are looking to develop new products that will further innovate the auto industry and grow the company. I've gotten to be apart of the idea creation and elmination stage of our new product design, which has been fun, and now I've been put in charge of designing the interface for our first new product that will hopefully launch at the end of the year. This project will be a web app built into our growing suite of apps hosted in Angular and will leverage my machine learning skills, which I've kept sharp since leaving Mocavo through Udacity courses and side projects. I'm excited for ASV's future, it feels like we are right on the precipice of having some explosive growth and innovation.