On 2020-11-26 23:26:-0500, SteveL wrote: >I own a popular open-source based 3D printer. <snip> really worse than the >version you hoped to repair, or dramatically changed in ways that demand >relearning from the beginning. > >... I wanted to print - not test and debug code!
These are both situations I have experienced. I don't want to discourage independent dev. In fact, ham radio itself is a metaphor for this discussion, because have all sorts of user community dev, and some really creative ideas come out of that. But some of my thoughts apply to both areas. I do see in the ham community a rush to get products out the door, to get the next feature installed...at the sacrifice of explaining to the user body what those changes are, how well they were tested, and how to use them. Yep...the products themselves are a great help to the community. But most of the user community that I have directly interacted with has no idea how to dev a product, how to specify a requirement, how to specify a design, how to test the final product. Instead, users get to test and debug the results. I know from experience how much extra work is involved in doing the job correctly. I have heard community developers reply to criticism by saying how difficult it is to test every feature. I get it. Back in the 90s, I read an account in an engineering mag about upgrades to Cheyenne Mt. I'll gloss over the details. A company won the bid. The Feds agreed that it would take 4 years and 4$B to do the work. At the end of 4 years, the contractor came back and said that they were behind schedule, and it would take another 4 years and 4$B. The Feds said maybe, but not with you, and went out for bids again. They got a contractor who conducted business the way my company did. They came in ahead of budget and time. In the article, they specifically mentioned the processes that lead to their success. An engineer in one of our client companies showed me the article, noting that it was specifically about the business approach we insisted on. One of the engineers in that company asked me one day why we had so much paper, and did we /really/ need to discuss all that stuff. Couldn't we "just to it?'"? That same engineer changed his tune when we discovered a serious flaw in their design. (We were collab on a $10M project.) As a direct result of /our/ design and construction, that company became a market leader in a vertical market. So I encourage individual effort. I applaud it. I admire the creativity. But I'd like to have those creative individuals slow down, and perhaps collab with the right people to do a decent job, instead of foisting on the user base the responsibility of testing and debugging, and then "documenting", shotgun style, on fora and wikis. I'd like to think this comes across as a discussion point, not as whining. If engineers in large corporations don't follow this structure, it is not hard to imagine why community developers don't either. But this discussion is more about a social change over the past 40 years. I have a friend who works for a major car dealership. He said they have a constant stream of bugs that they fix, software and hardware. New car buyers are part of the "test and debug" community. ~R~ ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:Elecraft@mailman.qth.net This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to arch...@mail-archive.com
