Brook’s “The Mythical Man-Month” covers this well, and is still largely relevant even though it was published in 1975.
Anecdotally, I have been involved in late software projects, and as expected there were a few proposals such as “can’t we just add some contractors and speed things up”? Thankfully those managing the projects, in general, carefully explained the lead time for training on the codebase, how this would take time away from those currently working on the code, impact due to disruption, etc. Instead we would usually end up trimming a couple features for the first version, and to lower delivery time enough to be palatable.
I strongly recommend “The Mythical Man-Month” as well. After reading that book, I have found it much easier to see tell-tale signs of a software project going awry. That said, I am surprised the manufacturing company did not push out a small batch of boards (say 100), and send back to the company for testing. This adds lead time, but often avoids major financial catastrophe (such as this case). It can also save your customer money, if the drawing wasn’t quite as thorough as they thought!
Hardware prototypes can be absolutely crucial to determining if a) the drawing is correct b) it has been interpreted correctly by both parties and c) gives the manufacturer a chance to become comfortable with the build process and confirm the tiny details which are sometimes missing, even in the best drawings.
If this was a misbuild AFTER prototyping, the question turns to how - how did company process controls/QA allow a change to a previously approved build? How can the company prevent something like this again in the future?
A lot of food for thought here. Thanks!
She said there is a thorough control process for getting parts for your builds. If one was lazy, you (the tech) could save time by assuming you know what is best and take parts from other assembly lines near by. Potentially thinking “Flux is flux! It is all the same!”
She has been in the industry a surprisingly long time so she has the knowledge to observe the whole rapid growth and hiring phase and correlate that with poor quality. This clicked with me as I recalled projects that were mismanaged and how I was unable to steer the conversation effectively.
I find that the majority of CS majors have had to read it. The business manager’s I’ve worked with however tend to have not read the book. And when I have lent my copy out, the consumeristic nature of people (at least in the States) has led some to as me why I loaned them such an old technology book. Appearing to think that newer is better? :(
I really appreciate you sharing. Ideally, I am seeking more current and personal experiences to this ongoing issue. If we could quantify different managerial or personality types maybe there is a common dialect or way in which to communicate this concern and actually be heard. Or maybe you attack it on the front end with a basic risk assessment strategy for producing technology products (software, pc boards, etc).
I realize I’m probably dreaming… :-)
I almost appreciate it more when a patch is difficult to get merged. Yes, it takes more time and effort on my part (as well as others) but when you have multiple maintainers commenting on things from possible bugs, all the way down to coding and comment style, you know that it has been thoroughly vetted by at least part of the community. If a bug presents itself in that code sometime later, it also helps me feel a little better about having written that bug in the first place :)
As a mostly solo/freelance developer, I can relate to this: rigorous discussion is one way to sharpen your skills. The depressing thing is when the discussion isn’t constructive, but it really just stonewalling, with no intention of ever merging or helping you get to a merge-able state.