If Car Developers worked like Software Developers

Vibhor Mahajan
3 min readDec 14, 2022

Product Manager

The User Story
As a common person I would like to drive around my family of 4 in a car So that I can achieve my day-to-day common person commutes

Acceptance Criteria
1. We should be able to travel at an average pace of 60 kmph
2. The transportation cost should be affordable
3. The car should be durable and should sustain at-least 10 years of use in urban city driving and occasional inter-state trips. It should not require anything more than a regular maintenance cycle of about 6 months.
4. The car should work in a range of outside temperatures ranging from -5C to 60C

Photo by Oli Woodman on Unsplash

The Development Team

Photo by Aaron Huber on Unsplash
  1. I just came from a conference hosted by Ferrari 🏎️. They open sourced these cool new tools for building cars. We can 3-D print them and use them to build our new car! It will be a fun learning these tools and will look great on our resumes! But
    1. It will be really hard to add new members to the team later
    2. Many of the repair shops won’t have these tools or training to use these tools to fix the issues in the car later
  2. Let’s build 🛠️ our own engine! It’ll be fun right? 🤔 But
    1. The engine is critical to the success of the car and building one is not our expertise. We could have bought one from another company.
    2. We are not equipped to estimate how long it will take to develop an efficient engine and building one can risk the schedule and cost of the car development
  3. Ok. So, we are building the engine. I can only test the engine under development by attaching it to the rest of the car parts and firing it up every time I make a change in the engine. I also need the real fuel to test it while developing it. Please stock up a lot of it for my use! But
    1. I got some training on how to use cost-effective unit-testing but my manager denied my request to use these because I said it will take another 20% development time to use them.
    2. I’ve heard of unit-testing techniques such as mocking and stubbing. But I’m too busy to try those fancy unit-testing tools. Attaching the engine to the car and running it on every change is not an easy job. My project manager is breathing down my neck. I barely get to see my kids at home these days.
  4. 🛞 It seems like the breaks and the wheel rim belong together. Let’s weld the breaks on the rim. But
    1. It would have been cheaper to replace broken parts if there was no coupling between them
  5. In order to test the car in the extreme temperatures, I will have to drive it to the mountains to find a place cold enough 🥶 and later to the Lut Desert in Iran to test in the extreme hot 🌡️ environments. Oh and we’ll have to make these trips several times with many cars. But
    1. I could have developed a testing facility to simulate the extreme conditions locally at a fraction of the price 💰

Vibhor Mahajan is the VP — Software Product Development and Innovation at Trantor. His job at Trantor is to establish trust with new challenging accounts, develop novel practices, and scale software engineering teams. He provides consulting and thought leadership to help establish consistent and sustainable software engineering delivery.

https://www.linkedin.com/in/vibhormahajan

--

--

A Software Craftsman, he loves building Software Products, and high performance Software Engineering Teams http://bit.ly/2YaU6zY