Re: SDR-console 3.0.26 & 3.0.27 : cracks in audio


Allan Isaacs
 

Way back around 1971 I was part of the 3 month study team for specifying and costing the Ptarmigan System.
That was for British Army comms and was based on a brand new Plessey computer developed in-house. I asked our subcontractor how long they would take to write a compiler and their expert systems guy was wheeled in. How long? I should say 3 moths he responded... how many people? Oh.. just me he said.
The compiler was eventually written but I understand it was still being worked on after some 30 man years of effort. I didn't notice if the expert was wearing rose tinted spectacles...
Allan G3PIY

-----Original Message-----
From: main@SDR-Radio.groups.io [mailto:main@SDR-Radio.groups.io] On Behalf Of Rich NE1EE
Sent: 10 June 2021 11:57
To: main@SDR-Radio.groups.io
Subject: Re: [SDR-Radio] SDR-console 3.0.26 & 3.0.27 : cracks in audio

On 2021-06-09 18:57:+0100, you wrote:
On Wed, 2021-06-09 at 03:55 -0700, f1jek wrote:
- I understand but all programmer mistakes are stupid anyway´┐Ż
No, they are all caused by inadequate documentation. Someone else's documentation.
For 25 years I ran my own engineering company, and much of what we did was embedded software engineering. We followed IEEE standards for software development.

One day we were hired to do a small project as a sort of test. The client liked the way we presented, and said that they were hiring us because they suspected that they didn't do very well in the area of software /engineering/. They are a large developer of industrial systems.

So one of our engineers dropped by and started the process by interviewing their engineers and developing requirement specs for the 3 small projects. This consisted of cycles of interviews>write spec>review spec w client>clarify spec> etc, until we were satisfied that the spec was accurate and complete. This didn't involve as many person-hours as it sounds like, but was spread out over a week or three. Then, using the Requirements as a springboard, the engineer did the same for the Design Spec. It needed some effort to keep on track, because the client constantly made the same mistake that many do...they were confusing requirements with design with construction.

When the design was finished, the engineer asked for all the applicable hardware docs that they had, and left with them, asking if it were OK to call for clarification (yes) and saying that he'd be back with the results.

Later...the engineer returned with 3 software products. Two were flawless; 1 had a small error. The client was stunned. I learned later from them that one of their engineers had commented to another as our engineer left to complete the project "there goes either the smartest person I have met or the stupidest. I don't understand what we just did. He didn't ask any of the questions I would have asked." They were so pleased with the work that they hired us for several large projects.

I recently posted an engineering comment on a ham-related list about some hardware and software mods for a project underdevelopment, complete with schematics and simulation results. The response from a developer was to the effect that I "must be wrong", though he had not bothered to read the 1000+ pages of hardware docs available from manufacturers. ((I had read the applicable parts.) He wrote, incorrectly, that the circuit is "probably" not what I described! His comment was up voted. ...I was not wrong; I had a working prototype. But I got the message, and stopped contributing.

"Programming" is one thing; "software engineering", another. "all programmer mistakes are stupid anyway"? We all make mistakes. That is why in my company everyone was expected to get his work reviewed in detail by another...to catch those mistakes. The reviewer was expected to ask probing, sometimes embarrassing, questions. Of course, the whole point was to discover flaws before the client did, so no question was really embarrassing, even if the author had to say "Gee, I had not thought of that." The idea was to critique the work, not the person.

I agree with (the way I interpret) "caused by inadequate documentation." I think that most ham projects are characterized by brilliant work, compromised by inadequate attention to requirements, design, and docs. As painful as it is, and I know from decades of experience, developers need to pay more attention to those items, and slow mad rush to release. At my company, we found that we always came in ahead of schedule and budget, with superlative products, because we spent the time to do software engineering correctly. Would you have a house built by having a load of pipes, lumber and so on dumped in your yard, and telling some contractor to "just build it"? This is not limited to hams...I recently spent time with some scientists who were doing brilliant work, and they paid the price for the same lack of rigor. In several cases, they had to hire other PhDs to reverse-engineer what they had done, and document it. Imagine the cost of hiring a few PhDs for a year just to "discover" what had already been discovered!




--
72/73 de Rich NE1EE
The Dusty Key
On the banks of the Piscataqua

Join main@SDR-Radio.groups.io to automatically receive all group messages.