Take inspiration from the physical product development process

Wednesday December 29th 2021 by SocraticDev

Robert States is a mechanical engineer specializing in the design of plastic products. Interviewed about his experience as a partner in the consulting firm Stress Engineering Services inc., the engineer describes himself as the character of the film Pulp Fiction: Winston Wolf. This character played by Harvey Keitel called urgently to cover up the result of a murder committed in a car by one of the main characters of the film.

"I am Winston Wolfe. I solve problems."

"It's about 30 minutes away, I'll be there in 10."

In this problem-solving interview, Robert States highlights the benefits of a consulting firm in the development of manufactured products for highly regulated industries such as the medical industry.

As a software developer, my curiosity was aroused: does the software industry have any lessons to learn from the process of designing physical products?

In terms of long-term reliability.

Think hard software!

'Been there, done that' mindset

The advantage of an experienced consultant is to have experienced the same difficulties and to have solved them over and over again. When the engineer is involved in the design process, he is able to plan the critical steps; where the team is going to have difficulty. Especially its contribution by offering robust and proven solutions.

In addition, the engineer offers a predictive analysis approach. This is the development of physical products based on advanced simulations. Model-based simulations improve product reliability and accuracy. If the product does not perform as expected, either the model is incorrect or the product contains flaws that must be detected.

four product development anti-patterns leading to failure

Robert States lists four common ways that lead to product development failures.

  1. When the engineer asks the project managers 'How did you get there?', The stakeholders plead ignorance. They ignored fundamental elements necessary for the success of the product. In particular, they did not know that they had to know what they had to know (!). ('I didn't know I needed to know that ...')
  2. The stakeholders do not listen to each other and do not maintain a dialogue. Everyone talks about their needs without listening to others. They avoid dealing with the issues raised by the other party.
  3. Teams are constantly trying to reinvent the wheel instead of using proven solutions. The catch is that instead of benefiting from each other's experience, it imposes a learning curve on everyone in order to get up to speed before embarking on product development.
  4. Rapid prototyping also brings its share of problems. By presenting a prototype that 'works', especially to non-experts, you get too much trust too early in the development process.
an organizational anti-pattern leading to failures

A high turnover rate within an organization is problematic.

In such an organization, there is no experienced person who knows the history of the organization's projects. According to Robert States, it is essential that these experienced people are fully included in the development of projects in order to impart 'tribal knowledge' to new members of the organization.

conclusion: should we apply these tips to software development?

Can we really apply these tips to software development? In an ideal world, software is a fully malleable product requiring minimal planning. This is true if you have the time, money and energy to start a project regularly from scratch. For example, the SocraticDev blog you are reading now relies on a software solution: custom code on top of the GatsbyJs framework. A GraphQL resource file management system. Surprisingly, the code hasn't changed much for two years. Even if it's 'just' code, the fact remains that it would be a significant effort to have to reopen the code regularly.

So taking the time to design a software application correctly from the start results in increased reliability and a product that delivers on its promises at a lower cost.