Sep 11 2021

Elon Musk on Design, Development, and Manufacturing

Recently, I went down a SpaceX rabbit hole where Elon Musk shared his thoughts on design, development, and manufacturing. Here are some choice insights from Elon as he talks about the SpaceX Starship, a fully re-useable rocket.

  • If a design is taking too long, the design is wrong and therefore the design needs to be modified to accelerate progress.
  • One of the most fundamental errors we’ve made to advance development is to stick to a design even when it is very complicate and to not strive to delete parts and processes.
  • Everyone is chief engineer, everyone must understand how all the systems work so that you don’t have subsystem optimization.
  • The product errors reflect the organizational errors. Whatever departments you have, that will be where your interfaces will be. Instead of questioning the constraints, one department will design to the constraints that the other department has given them without calling into question and saying those constraints are wrong.
  • You should actual take the approach that the constraints you are given are some degree wrong, the counterpoint would be that they’re perfect.
  • One of the biggest traps for smart engineers is optimizing a thing that shouldn’t exist.
  • We often try to answer the questions we are given, instead of questioning the premise of the question itself.
  • We can produce boosters and ships way easier than we can make the launch site.
  • It’s 10 to 100 times more effort to design the manufacturing system than the engine (a first of its kind).
  • The amount that goes into the design rounds into zero, relative to the amount of effort that goes into the manufacturing system.
  • All designs are wrong, it’s just a matter of how wrong. Everyone is wrong, no matter who you are, everyone is wrong some of the time.

In large part from his experience at Telsa, Elon is now using this Five Step Process at SpaceX.

Five Step Process

  • Make your requirements less dumb, your requirements are definitely dumb. It doesn’t matter who gave them to you. It’s particularly dangerous if a smart person gave you the requirements because you might not question them enough.
  • Try very hard to delete a part or process. If you are not occasionally adding things back in, you are not deleting enough.
  • Simplify or optimize. The reason this is the third step is that it is very common for a smart engineer to optimize a thing that should not exist.
  • Accelerate cycle time, you are moving too slowly but don’t go faster than until you’ve work on the other things first. If you are digging your grave don’t dig faster, stop digging your grave.
  • The final step is automate.

About the above process, Elon states the following.

  • I’ve personally made the mistake of going backwards on all five steps, multiple times.

Mar 5 2012

It’s Always Your Problem

As a business, if any client has any sort of problem using your software then it’s your problem. Non technical users will have trouble using your software because of an array of issues, such as permissions, settings, configurations, other software, and external devices. No matter what, you have to make the effort to get them started using with your software or not. I’ve seen issues at different client sites because one software application required one version of Java and another required a newer version. Typically you can have multiple version of Java on a computer, but these two applications demanded that only over version exist and that it be the one they require. I’ve seen issues where end users print from an application and complain because they don’t see the document printed in their laser jet, it was printing in another printer in another floor and they didn’t know how to configure it correctly.

As a development lead, if any programmer has any sort of problem with your architecture then it’s your problem. If someone doesn’t understand an design and they have to work with it, they will make changes that can cost you in the long run. If you make a system overly complex, there will be a time that you will have to delegate that to someone else and they will not understand it as deeply as you and will make changes to fix the bug of the day, but cause another problem to be discovered later.

Whether an end user doesn’t know how to change the printer or a new developer doesn’t know how to implement your design, it’s your problem and it should be addressed with something other than blaming the confused.

Sometimes it’s because you took on the wrong client, or hired someone without the technical background, but it is still your problem. Often times, the problem is basic communication and availability of training material. Always, examine these situations and see how you can improve the process, training, and communication of your team.


Dec 16 2011

Android Lacks Polish

I’ve been an Android user since the HTC G1 first came out. Since then, I’ve had and used the Google Nexus, HTC G2, and the Dell Streak 7. I’ve tried to like my Android devices but they lack polish or frustrate me in several other ways. The first annoying lack to details is noticed immediately as soon as you un-box the device. Just turn over the device and you’ll see three or more logos, the maker logo (such as Dell, HTC, or Samsung), the carriers logo (T-Mobile or Verizon), and the product name or other insignia. Apple products just have the Apple logo. On Android devices, you’ll have different logos each placed on the back plate separately, the vendor’s logo will be etched into the back while the carrier’s logo will be some cheap vinyl sticker placed afterward.

My personal pet peeve with Android devices is the craziness with moving apps from the internal device’s memory to the external SD card. Even relatively recent Android devices such as the Google Nexus and Dell Streak 7 have less than 1GB internal memory so if you download a lot of apps you’ll soon need to move apps around to the SD card. But some apps you can’t move to the SD card so that presents a different issue.

Who cares if the phone’s memory can be extended by using higher capacity SD cards if a one year old device can’t even be upgraded to the latest Android version. So the whole thing with extensible SD cards and moving installed apps from the internal memory to the SD card I find completely and frustratingly useless. The whole concept of an Operating Systems is that best manages the resources of the device, the Android OS should best manage installed applications in either the internal memory or SD based on some intelligence. Why am I doing Android’s job?

Another concern I have with Android devices is that they usually come with a lot of pre-installed apps. For example, my Dell Streak 7 came with Kongregate Arcade app which I can’t remove and reclaim the wasted internal memory. Similarly, carriers and vendors add and customize Android so that no two devices have the same user experience.

My last concern with Android’s lack of polish is its dark goth color scheme. Most application’s menu and option screens are as if they were designed by a goth listening to The Cure. The Android UI design is not “Just Like Heaven.”


Sep 30 2011

Avoid overloading Meaning to Existing Database Column

I’ve always found that when defining a database table it is always best to create a integer primary key, even if a unique key such as social security number, ISBN, or some other business value. Recently I had to go through the unpleasant process of updating a database table and associated scripts, resources, and code that had used a business attribute as the primary key but because of business requirements it was no longer unique and had grown to have different meanings. Because your business requirements will change, don’t use business attributes as primary keys for you database design. In addition, don’t overload attributes to more than one meaning. For example, the database that I was working with had a database column called Sequence that functioned as the primary key, the line number, and a workflow execution order to process the data. It is a source of confusion and bugs to overload one attribute to so many different meanings.


Dec 29 2010

Threadless

I recently received the Threadless: Ten Years of T-shirts from the World’s Most Inspiring Online Design Community book. I’ve never submitted a design or voted for a design on Threadless but I wear shirts and I’ve always been a fan of their products. The book was in my wishlist and someone in my family bought the book for me as a gift. The book is full of great designs which have been used on Threadless shirts over the past ten years. While reading about how Threadless started and the company culture one thread, pun intended, stood out. The community is the key to the success at Threadless. Threadless started out in a thread post in an online design forum where designers submitted designs for review and the best one was printed. As a business model, it seems very straight forward, but you can’t stress enough how important the community is to the company. As a classically trained software engineer, I approach everything from the aspect of technical specifications and software requirements so when I see a site like Threadless I think of the software features, like voting, commenting, etc. But reading this book I realized that Threadless is not a technology solution, but a living community. Fostering communities trumps technology. As engineers, we often quote and misunderstand the saying, “If you build it they will come” to mean technology focused website. At least, this was Google’s mistake with Google Wave, they built a great technology but no one came. I now believe that what the saying is referring to is not technology, but community.

Here are some other things I learned from the book. Threadless included free stickers with every order. Stickers have been used for years to spread word of mouth, and it pre-dates viral marketing. Stickers are a physical real world viral marketing vehicle. Everyone that has been to a developer conference has seen a conference speakers’ Mac Book Pro full of web 2.0 logos and stickers.

Networking is really important. For Threadless, this meant sharing office space with fellow designers and developers. Creating shared experiences builds community. Participating in events is fostering community. Provide the tools and means for the community to spread the company message and brand. Jeff Howe, who is credited with coining the term crowdsourcing, said the following in an essay in the book. “It takes a special company to understand that their ego – their creativity, their brilliance, their ideas- are welcome, but not necessary.  What’s necessary is the room in which the party takes place.”

Threadless

Threadless Designs

Here is my favorite quote from the book. “Jacob and I also began teaching a course at the Art Institute of Chicago.  That made us feel a little better about dropping out of school.”


Nov 10 2010

Collection of Favorite Programming Quotes

I’ve always loved to read collections of inspiring quotes. For one, you can read one quote at a time and you don’t have to worry about following a plot or losing your place in the book because each quote is self contained nugget of wisdom. At least that is how I felt when I first read Words I Wish I Wrote: A Collection of Writing That Inspired My Ideas by Robert Fulghum. Since first reading Words I Wish I Wrote, I have collected programming related quotes from blogs, books, and articles that I’ve read. Many, but not all, of the quotes that I’ve collected have ended up as a blog post here.