Sometimes companies have multiple versions of a custom Android product to develop at the same time. In these cases, the core technology is the same, but there are differences with the peripheral components and casing. Intuition says that since the products use the same core technology, working multiple projects in parallel is the most efficient way to manage development. Experience says otherwise. This article breaks down why intuition and experience, in regards to parallel development of custom Android hardware development, don’t always agree with each other.
When going through the product development process, we find that each custom Android product has nuances which require special attention to get right. Working through unknowns is common with any custom product development. If there are smart engineers, with a lot of custom Android development experience, handling the hardware development, they’re likely to figure out the unknowns quicker than less experienced engineers. In the same sense, when starting with one version, lessons learned from developing the first product often apply to all models. Having as many common parts as possible improves efficiency for the next version’s development. Ideally the same PCBA is used throughout the different versions. When that’s not possible, the versions must at least share the same reference design and firmware. Otherwise it would be two different products, not two different versions.
Jugglers say that juggling three balls is so different from juggling four balls, that they’re two different skills. Simultaneously developing multiple versions of a product also requires different skills than developing one. When developing one product, the engineers are always busy with something. It may be that not all engineers are always busy, but at least one engineer is always busy working on relieving the project’s current bottleneck. With simultaneous product development, rather than focusing on the product, the project manager needs to focus on resource optimization. Successful product development happens when the team leader can focus on intricate details, rather than spend their time with personnel management.
Testing and problem solving are the longest and most unpredictable aspects of development. Going through those with one model at a time limits the variables and focuses the team’s attention. The focus on one product, rather than juggling multiple, results in faster solutions, which generally apply to all versions. Getting through the first version clears the path for future versions. Each additional version becomes easier to develop. By going one by one the engineering resources don’t get stressed out and flustered by too much happening at once. This is an intangible reality which becomes clear through doing.
One of the core principles of efficient development is to reduce variables as much as possible. Projects with the clearest path for development get done the most efficiently.
