More skeletons out
-
honey the codewitch wrote:
I am extra careful with my code, and it makes me nervous, but good nervous because I check my work.
That's how I feel when I write any code. Even if the consequences are "only" financial, the last thing I want is for the blame to be laid at my door.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
I have levels of careful. For most professional code, my careful involves making sure there's a QA/QC process in place because I don't believe people are effective at testing our own code, for the same reason we aren't good at proofreading our own resumes or CVs. So there's a limited amount of due diligence I employ before I decide that I'm wasting money. Because I won't be able to catch my corner cases anyway. Now, I could do TDD for this particular project, and that might be the best way to go about it, even though *usually* my firmware is small enough, and the test matrix small enough that it's not cost effective. But usually I'm not looking after animals. However, I don't own this codebase. I'm just a consultant doing some of the development.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
https://www.popsci.com/technology/boeing-faa-audit/ Not sure how long before this ends well.
The conversion to McDonnell Douglas management philosophies is nearly complete. At the time of the great merger between Boing and McDonnell Douglas the DC 10 fiasco was rapidly sinking that company. After the merger the cancerous "Maximizing Shareholder Value" took hold in Boing and the march to lower levels of quality had begun. The share value soared and nobody cared that Boing QA teams were decimated in the process. Boing engineers understood that people make mistakes and in a complicated machine like an airplane mistakes could have deadly consequences. So assembly teams had extra time factored into assembly to handle the inevitable delays incurred when QA caught mistakes. But this raised costs and lowered productivity. This did NOT maximize share holder value. QA teams became single QA persons who could only enter problems into a system and no longer affect the production of a plane. Assembly team size also shrunk and strict assembly times were enforced. Missing bolts for a door, put the door up, enter the missing bolts into a system and move on. Somebody else would handle the problem later. Now the merry-go-round has stopped and the FAA is left holding the bag as the big bad government regulator that has to point out the glaring deficiencies. Boing management is left with hollow promises to make things better but the excess money is gone, gobbled up by stock buy backs that "Maximized Share Holder Value". There is no spare money to throw at increasing team sizes without affecting the value of the stock. Like the DC10 of old, the customers are voting with their feet and refusing to fly on the Boing Max planes. Airlines are starting to review their long term orders and reducing the demand for these controversial airplanes. Its just sad.
-
How much of really bad code have you seen? I've seen plenty. Definitely more bad than good. I've got this theory that at least 90% of programmers are a bunch of bunglers who don't understand basic OOP principles, or any other programming best practices for that matter. I also think the programming industry isn't unique. Which would mean at least 90% of all people are just bad at their jobs, including builders, doctors, surgeons, politicians, judges... :omg: And the remaining 10% still make mistakes :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
We're unique in that we haven't been around as long as those other professions. That means our bad ones tend to be worse, and on average, by comparison, so are we. Industry maturity thing. I think this one stays a baby for awhile though. Thanks to awful entities like AAPL, we're doomed to an unnatural level of combined ignorance and consumption for a time to come.
-
Sander Rossel wrote:
who don't understand basic OOP principles, or any other programming best practices for that matter.
Not understanding that doesn't necessarily implies that you write unsecure code. If I had to choose as a user, I would prefer to have a spagetti safe working code in a ECU than a very structured and clean code that contains bugs in it for the same ECU.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
The chances of spaghetti code working well and being safe are a lot less than neat and clean code being safe and working well. Plus spaghetti will raise chances on bugs considerably on any future update. "There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it." - Tony Hoare
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Sander Rossel wrote:
Which would mean at least 90% of all people are just bad at their jobs
90% of Science Fiction is crud. But then 90% of everything is crud. -- Theodore Sturgeon
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
I don't know who this Theodore Sturgeon is, but he and I are of the same mind on this one :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
The chances of spaghetti code working well and being safe are a lot less than neat and clean code being safe and working well. Plus spaghetti will raise chances on bugs considerably on any future update. "There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it." - Tony Hoare
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I use spaghetti sometimes to proof a complicated design, before I rewrite. I got crap for it here in the lounge. But I don't see the difference between using VS Code vs using pen and paper, except a compiler can check my work with the former.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
https://www.popsci.com/technology/boeing-faa-audit/ Not sure how long before this ends well.
Nothing describes it better than a golden oldie - leaving on a jet plane janis joplin [^]
-
I don't know who this Theodore Sturgeon is, but he and I are of the same mind on this one :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
[Theodore Sturgeon - Wikipedia](https://en.m.wikipedia.org/wiki/Theodore\_Sturgeon)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
https://www.popsci.com/technology/boeing-faa-audit/ Not sure how long before this ends well.
Read the article. At least one of those incidents had nothing to do with Boeing and everything to do with bad timing - foreign object damage to an engine. Also, the New York Times reported earlier this week that Alaska Airlines had ignored a cabin pressurization warning light on the 737 that had the door plug blow out. AA is really lucky no one was injured or killed as they would be on the hook for flying an aircraft with a safety warning light illuminated.
-
How much of really bad code have you seen? I've seen plenty. Definitely more bad than good. I've got this theory that at least 90% of programmers are a bunch of bunglers who don't understand basic OOP principles, or any other programming best practices for that matter. I also think the programming industry isn't unique. Which would mean at least 90% of all people are just bad at their jobs, including builders, doctors, surgeons, politicians, judges... :omg: And the remaining 10% still make mistakes :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sander Rossel wrote:
I've got this theory that at least 90% of programmers are a bunch of bunglers
My theory is that 80% of people are average. 10% are excellent. 10% are not very good. That after all is basically how normal distribution works. But of course one must keep in mind that people are complex. As such they might suck at one thing but be great at another. Time, complexity and economics will always have an impact on any idealization that one might have started with. Not to mentioned efforts that and up only half done due to some 'better' idealization halfway through. So no point in me agonizing over might have beens when I wasn't even around to see what those people had to go through.
