Moving Parts

"For each ticket you do, please ask yourself when you get done: 'Did I make the entire system I am working on better?' If you cannot answer, 'Yes,' I implore you to address that in the craftsmanship of your work.

You see, ultimately you, the engineer, are the arbiter of _done_. Thus, you are the ultimate source of all technology success. It’s a heavy burden. Carry it well." - A really good person that will remain anonymous unless he/she wants to claim credit for this quote

Elon Musk founded the company Tesla on an absurd idea. Taking a bunch of Lithium Ion laptop batteries, bundling them together, and creating a pure electric car was absolutely nuts. And yet… Tesla keeps making cars that are critical (Source) and commercial successes and their automobiles exceed all expectations. As of this writing, the Tesla Model S, with the performance package and dual motors, is now capable of accelerating from 0 to 60 in  “Ludicrous Mode” in 2.4 seconds (Source). This time beats the pants off of established players in the performance game like Porsche, Lamborghini, Ferrari, and any other car company - and they are doing this in a luxury sedan, not a sports car.

Not only do they provide blazing fast acceleration and near 300 miles of range on a charge, Tesla has established themselves as a “tech” centric car company. Their vehicles have gigantic 17” monitors in the console. Heck, some cars even drive themselves (Source). As a Tesla owner and a tech enthusiast, I find all of these extras amazing or annoying; depending on the time of day.

Recently, there was a software upgrade that was received by my car. After the upgrade, the handles on the driver’s side of the car stopped being usable. Ordinarily, the handles lie flush with the car. When the car is stopped and the driver approaches the car, the handles automatically pop out. Once seated with the doors closed, the handles retract. It’s truly magical, right up to the point when it stops working.

The Model S first arrived on the scene in 2012. In the years leading up to the launch, I am sure that there was an engineer who came up with the idea of the retractable door handles and was very proud of this accomplishment. After all, when the door handles lie flush with the body, it does cut down on the coefficient of drag thereby extending the overall range of the vehicle and the number one concern of making an all electric car was winning the battle with the consumer over the dreaded “range anxiety” phobia (Source). Anything that extended the driving range of the vehicle had to be good. Right?

After my incident with the aforementioned software update and the inability to open the door on the driver’s side, I spent a decent amount of time on various Tesla forums. It became readily apparent that for all of the great, innovative things that Tesla does, the least liked feature is the door handles (Source). If the door handles are broken, the owner is looking at a roughly $1,000 bill (Source). Sure, when you first go to the Tesla showroom and you see the door handles magically pop out, you think, “Cool!” But now that the same feature is costing you a grand, you think it sucks.

In reality, the novelty wears off pretty quickly. After a while, as a driver you cease to even notice - that is until it stops working. Does it lower the coefficient of drag? Well, yes. But… I cannot find any relevant sources that will quantify by how much. Is this adding 1 mile of range or 10? My guess is it’s probably close to less than one and has more to do with the coolness factor than any practical application.

As for my experience with the dreaded driver’s side door handles - I called Tesla as I am still under warranty. I was advised to, and I’m not making this up, reboot my car. As luck would have it, rebooting the car did the trick and the door handles now work as expected. No repairs were needed.

However, I thought a lot about this experience. An engineer came up with a design that would ever so slightly improve something that actually mattered. However, in doing so, the engineer introduced, in this case literally, moving parts. The benefit of the moving parts were minor, but the complexity of the feature was not insignificant. This feature has cost Tesla some customer loyalty and satisfaction and tarnished their reputation somewhat.

In software, this kind of thinking happens all the time. There is almost never a “right” solution. There are multiple solutions to every problem. There are tradeoffs to every proposed solution like how long will it take to implement and how well it will perform, but what is often overlooked is the question, “Who is going to maintain this?”

In the godforsaken software engineering industry, according to the folks at Fast Company, it is advisable to change jobs every three years (Source). They go on to say that workers who stay in their jobs make up to 50% less. While I am not claiming the information in said article is accurate and I cannot provide an actual metric to how often software engineers change jobs, I will say, anecdotally, it happens all the time.

So, if a really smart engineer looks at problem and designs a solution that does a couple of unimportant things really well, but is super complicated - it might not be the right solution. As I sit here and reflect, midway through my own career I had a startling thought. I am over twenty years into a career in a field where intellect is fetishized and shiny objects du jour rule decision making. And yet, I have a below average intelligence, barely able to walk and chew gum at the same time. The thought crossed my mind that my lack of brilliance is actually an asset and not a weakness as I tend to write extremely simple solutions without a lot of moving parts.

Instead of over optimizing for theoreticals that don’t really matter, I spend most of my time making sure I nail all the must haves. I add in a little documentation and then I move on to the next thing. I have this overall philosophy that as I sit and write this, there is a kid that is in their senior year of UT having a drink on Sixth Street. While he or she may be care free right now, enjoying their last year of college, in a few months this individual will be wanting to start their career. I would be honored if a reasonably smart recent grad with a good attitude was handed my work to extend and maintain.

Being replaced by a fresh out of college graduate is the furthest thing from an insult. This is my mission at work. In all likelihood, a fresh out will destroy me in any discussion of algorithms or Big O notation or any of the other academic stuff I never studied. However, they have likely not worked together as a team, done pull requests, tried to get business requirements out of business users, or understood how difficult it is to get stuff done in the work environment. My code repositories do what they say they and even have a little documentation and some comments to help a newbie get started. I always expect to have someone else maintain it later, so I think a new grad should be able to clone my work and add a feature. There is a ton of value to this and I would take it as the ultimate compliment if they could be successful. It means that I understood the original problem, wrote maintainable code, and got things to a certain point that it could be turned over to someone to continue working. The heavy lifting is done and I can move on to the next problem.

Recently, I had an epiphany on how we could do data extracts at work. I was handed a list of challenges like managing the connections to the MySQL database and being able to handle a certain volume of customers. I gave it some thought and came up with a design that seemed very clean, powerful, and yet extremely simple. It used various components of AWS, scaled out beautifully, and would cost pocket change to execute. I did a quick whiteboarding session with some coworkers and once I pitched it, most people seemed pretty enthusiastic. I took the whiteboard sketch and put it into a more formal architecture diagram along with a high level overview of the problems the solution was trying to solve and published it internally. I received a lot of compliments and was shocked at the end of the day I was told that we should be using a different tool.

I don’t want to go into the specifics, but the proposed tool is intended to be used for situations where there are well over 1,000 transactions per second. The typical use case would be for an Internet of Things application or aggregating web logs. Our use case was nowhere near this threshold. In frustration, I tried to explain that the counter to my solution was like having a problem with how should you cut a cake.

Me: Let’s use a knife.

Architecture: Let’s use a chainsaw.

Me: OK, I can’t deny that a chainsaw can be used to cut a cake, but doesn’t that seem like overkill? I don’t even know how to use a chainsaw and while I can learn, it just seems completely unnecessary.

Architecture: But chainsaws are much better at cutting things than a knife.

Me: I’m not trying to cut through a log. I want to cut a cake.

Architecture: What are you going to do when you’re cake gets to be 10 feet tall?

Me: No one is ever going to make a 10 foot tall cake. It’s not going to happen. You clearly decided you wanted to use a chainsaw and now you’re making up hypothetical situations to validate your decision.

Architecture: Not ah.

Me: I’m taking my ball and going home.

Software is dominated by smart people doing dumb things. I would like to think that what sets me apart is that I am a dumb person doing smart things. There are infinite ways to take a relatively simple problem and provide a complicated solution. To be truly successful, a good engineer must break the problem down and provide a simple and maintainable solution no matter how complicated the problem. There are no bonus points for using a shiny object and even if it looks cool on paper, remember the Tesla door handle. It provides very little practical benefit besides looking cool. Eventually, everyone forgets about it until it stops working.