Software is stupid, programmers are overpaid poets.

[Vtile]

Being on both sides of the fence the biggest problem is that both disciplines do not cooperate more with eachother. It is not or the HW eng or the SW eng fault if problems arise, stop blaming eachother and take a look in each others kitchen before starting bitchin.

SW has become massive the last decade. Many HW eng's have no clue how many locs are written and that it is virtually impossible to prevent all possible conditions, test all forks and all possible outcomes.
Very expensive software, tests the code and tries to find all unhandled situations and reports issues.
We once had five sw engineers work three months to get rid of all the possible issues that came from two months coding, it can be that complex.
than most modern code use open source third party stacks what is in those, or do you think those are perfect? Do they really behave as documented under all conditions. Can they handle gracefully all input parameters?

When I started 20+ years ago we had 3x more HW engineers than emb. SW engineers, we now have 20x more SW engineers than HW engineers, do you really think that is because the Company does not care? Or does it want all the latest and greatest "features" that clients can think of in their product?

This or that, but the situation is shit.

[Kjelt]

Being on both sides of the fence the biggest problem is that both disciplines do not cooperate more with eachother. It is not or the HW eng or the SW eng fault if problems arise, stop blaming eachother and take a look in each others kitchen before starting bitchin.

SW has become massive the last decade. Many HW eng's have no clue how many locs are written and that it is virtually impossible to prevent all possible conditions, test all forks and all possible outcomes.
Very expensive software, tests the code and tries to find all unhandled situations and reports issues.
We once had five sw engineers work three months to get rid of all the possible issues that came from two months coding, it can be that complex.
than most modern code use open source third party stacks what is in those, or do you think those are perfect? Do they really behave as documented under all conditions. Can they handle gracefully all input parameters?

When I started 20+ years ago we had 3x more HW engineers than emb. SW engineers, we now have 20x more SW engineers than HW engineers, do you really think that is because the Company does not care? Or does it want all the latest and greatest "features" that clients can think of in their product?

This or that, but the situation is shit.

Thanks for that elaborate analysis and insight.
Hardware also fails
https://www.eevblog.com/forum/projects/lots-of-failing-outdoor-led-lamps-very-long-overhead-mains-cable/
and people are demanding quick release of apps and features.
Takeaway everyones smartphone, kill Linux, OSX and Windows and lets all stop using computers because they have bugs.
Lets face it life is not perfect and if society does not tune down on speed of progress this will only become worse also on the hardware side where the customer will be the tester.

[vodka]

The usual way to fix such a bug is to just try doing the thing in a slightly different way and see if the issue disappears.

How is that a problem? Often the first step to locating a bug is when it occurs and what changes will cause it to not occur. There are people who understand the lower layers, so communicate with them and they will help you with your issue. Isn't it the same thing true in hardware? Do you understand the design decisions in an ic that might be causing you problems?

Although I do agree there is too much complexity and abstractions quite a lot of software, especially things using "web technologies" (looking at you electron).

Yes but i mean the nonsense bugs that you have no idea why they happen and the documentation doesn't say anything about it and the layers underneath are not in your control.

For example i had a case where i was using the .NET chart control in C# and came across a bug where the whole program would suddenly crash inside of the paint calls to the controls. The debugger doesn't really give you any details where it happened, just tells you what form window the event handler crashed on, but i knew it was the chart controls fault as it only happened when i did stuff to it. If it had the source code for that control then it would likely point you into it and where the crash happened. Normally the this chart control has some safeguards inside it that draw a big red X mark across the control when it gets too confused or misconfigured to draw something reasonable. Well they forgot to safeguard against this overflow that happens if your charts Y axis has values above about 1 million and you zoom into a small part of the chart. Okay so then il just wrap a error handler around it to catch it so that my program doesn't crash on the spot but just shows an error text or something. Well... the mechanism that calls events is deeper down in .NET so i can't just wrap a Try statement around it, nor can i wrap the code that's causing it in a Try statement since i don't have the source code to the chart control. Consulting the documentation says that it should display a red X when it encounters an error. Don't think anyone at microsoft would be willing to help me with the problem, but if enough people complain they will probably fix it in the next version of the .NET Framework.

I guess it is a bit similar in hardware, but the layers underneath tend to be simpler than these massive software stacks that modern code runs on. So its easier to properly document them and debug them. Tho when writing hardware drivers i do run into cases where something is just plain broken. For example on TIs OMAP processors the SD card controllers buffer full flag was always zero, it supposedly worked for DMA transfers but manually reading it doesn't. The fault was not yet documented in the PDFs but the solution was to instead wait for the buffer empty flag(that worked fine) and fill the buffer with how ever many bytes the buffer is supposed to be able to hold.

I know .NET documentation is a shithole. You lost many time searching among class, methods ,etc. I yearn the old programming reference minibook  that had my father: all the function of the language, fast for searching and very clean.

You have many valor for using the .NET debugger, it is very messy. When i tired to see the .NET debugger, i usually use messagebox for debugging the source: more faster and less time.

[filssavi]

The problem Is not software itself, but the ship barely functioning maybe beta (sometimes alpha) builds to the customers using them as guinea pigs  and then patch it later as bug reports arrives because hiring a bunch of people to test shit and find bugs is much more expensive than a half assed PR blogpost when shit inevitably hits the fan...

the biggest difference between HW and SW is that releasing a software patch is free meanwhile releasing a hardware patch (recalling a faulty product) is insanely expensive (just ask volkswagen), do you want peoples shipping quality software start imposing heavy fines and taxes on patchs and bugfix releases and see how the whole industry will focus on quality

[vodka]

The problem Is not software itself, but the ship barely functioning maybe beta (sometimes alpha) builds to the customers using them as guinea pigs  and then patch it later as bug reports arrives because hiring a bunch of people to test shit and find bugs is much more expensive than a half assed PR blogpost when shit inevitably hits the fan...

the biggest difference between HW and SW is that releasing a software patch is free meanwhile releasing a hardware patch (recalling a faulty product) is insanely expensive (just ask volkswagen), do you want peoples shipping quality software start imposing heavy fines and taxes on patchs and bugfix releases and see how the whole industry will focus on quality

The great trouble that has the software is the quantity of lines of code, many are useless. Adding the programming paradigm POO and the efficient like JAVA for print a line by screen ,it needs four lines of source. Now , you imagine a complex system like SAP. Who is the brave that will debugger for seeking the fail and correct it?
Economically, debugging is expensive on money and time, more easier is doing a new function and patch the error when it is produced, but against the size the program grow and  it will spend more resources.

An other thing , patching is more cheaper than other options but never free, less that the corporations pay the programmers with a rice bowls.

[Len]

(a bunch of insulting BS)

Thank you for explaining my profession to me, dryjoints. Now please tell us what you do for a living, so I can explain to everyone how stupid and incompetent YOU are.

[llkiwi2006]

The usual way to fix such a bug is to just try doing the thing in a slightly different way and see if the issue disappears.

How is that a problem? Often the first step to locating a bug is when it occurs and what changes will cause it to not occur. There are people who understand the lower layers, so communicate with them and they will help you with your issue. Isn't it the same thing true in hardware? Do you understand the design decisions in an ic that might be causing you problems?

Although I do agree there is too much complexity and abstractions quite a lot of software, especially things using "web technologies" (looking at you electron).

Yes but i mean the nonsense bugs that you have no idea why they happen and the documentation doesn't say anything about it and the layers underneath are not in your control.

For example i had a case where i was using the .NET chart control in C# and came across a bug where the whole program would suddenly crash inside of the paint calls to the controls. The debugger doesn't really give you any details where it happened, just tells you what form window the event handler crashed on, but i knew it was the chart controls fault as it only happened when i did stuff to it. If it had the source code for that control then it would likely point you into it and where the crash happened. Normally the this chart control has some safeguards inside it that draw a big red X mark across the control when it gets too confused or misconfigured to draw something reasonable. Well they forgot to safeguard against this overflow that happens if your charts Y axis has values above about 1 million and you zoom into a small part of the chart. Okay so then il just wrap a error handler around it to catch it so that my program doesn't crash on the spot but just shows an error text or something. Well... the mechanism that calls events is deeper down in .NET so i can't just wrap a Try statement around it, nor can i wrap the code that's causing it in a Try statement since i don't have the source code to the chart control. Consulting the documentation says that it should display a red X when it encounters an error. Don't think anyone at microsoft would be willing to help me with the problem, but if enough people complain they will probably fix it in the next version of the .NET Framework.

I guess it is a bit similar in hardware, but the layers underneath tend to be simpler than these massive software stacks that modern code runs on. So its easier to properly document them and debug them. Tho when writing hardware drivers i do run into cases where something is just plain broken. For example on TIs OMAP processors the SD card controllers buffer full flag was always zero, it supposedly worked for DMA transfers but manually reading it doesn't. The fault was not yet documented in the PDFs but the solution was to instead wait for the buffer empty flag(that worked fine) and fill the buffer with how ever many bytes the buffer is supposed to be able to hold.

.NET 

I guess I had more luck with open source stuff. The one time I came across a compiler bug (in GHC, a Haskell compiler), people on the bug tracker helped me debug it and fixed it quite quickly.

[VK5RC]

Read the book, The Stupidity Paradox: 'group think', peer pressure, thinking only in your little area,  all have great potential for cock ups. With 'interconnectedness -  the ability to spread this is fantastic!

[filssavi]

The problem Is not software itself, but the ship barely functioning maybe beta (sometimes alpha) builds to the customers using them as guinea pigs  and then patch it later as bug reports arrives because hiring a bunch of people to test shit and find bugs is much more expensive than a half assed PR blogpost when shit inevitably hits the fan...

the biggest difference between HW and SW is that releasing a software patch is free meanwhile releasing a hardware patch (recalling a faulty product) is insanely expensive (just ask volkswagen), do you want peoples shipping quality software start imposing heavy fines and taxes on patchs and bugfix releases and see how the whole industry will focus on quality

The great trouble that has the software is the quantity of lines of code, many are useless. Adding the programming paradigm POO and the efficient like JAVA for print a line by screen ,it needs four lines of source. Now , you imagine a complex system like SAP. Who is the brave that will debugger for seeking the fail and correct it?
Economically, debugging is expensive on money and time, more easier is doing a new function and patch the error when it is produced, but against the size the program grow and  it will spend more resources.

An other thing , patching is more cheaper than other options but never free, less that the corporations pay the programmers with a rice bowls.

Don’t take it personally on I am about to write... but

That is bullshit, there is plenty of mission critical software running aircrafts, nuclear power plants ans so on that being held at much higher standard  and while it might not be 100% big free I never heard a nuclear meltdown due to a buffer overflow...

Now I’m not saying that Microsoft office should be held to the same standards but there shuld be a middle ground

And the argument about the lines of code is also shit, I can buy that for some crazy security vulnerabilities researchers find using deep knowledge of the whole stack

But let’a face it the 99.9% of the bugs are the same types we used to write in the ‘80  it’s 40 years ago...

[Vtile]

Being on both sides of the fence the biggest problem is that both disciplines do not cooperate more with eachother. It is not or the HW eng or the SW eng fault if problems arise, stop blaming eachother and take a look in each others kitchen before starting bitchin.

SW has become massive the last decade. Many HW eng's have no clue how many locs are written and that it is virtually impossible to prevent all possible conditions, test all forks and all possible outcomes.
Very expensive software, tests the code and tries to find all unhandled situations and reports issues.
We once had five sw engineers work three months to get rid of all the possible issues that came from two months coding, it can be that complex.
than most modern code use open source third party stacks what is in those, or do you think those are perfect? Do they really behave as documented under all conditions. Can they handle gracefully all input parameters?

When I started 20+ years ago we had 3x more HW engineers than emb. SW engineers, we now have 20x more SW engineers than HW engineers, do you really think that is because the Company does not care? Or does it want all the latest and greatest "features" that clients can think of in their product?

This or that, but the situation is shit.

Thanks for that elaborate analysis and insight.
Hardware also fails
https://www.eevblog.com/forum/projects/lots-of-failing-outdoor-led-lamps-very-long-overhead-mains-cable/
and people are demanding quick release of apps and features.
Takeaway everyones smartphone, kill Linux, OSX and Windows and lets all stop using computers because they have bugs.
Lets face it life is not perfect and if society does not tune down on speed of progress this will only become worse also on the hardware side where the customer will be the tester.

Sorry, I didn't attack against you, the opposite. The problem of overly complex SW creeping everywhere is just irritating. Reality, but still really irritating. Kind of like someone sell you a chainsaw with feature creep, but when you start to work with it you notice that the motor only runs 5 minutes. That would be essentially a worthless equipment. That said I have had two chainsaws, which have 0% of software, one had major design flaw in carburetor (german) and another had oilpump that did work only when rotated backwards (swedish). Needless to say they were the bottom of the lineup models, as I need one once in a year, still I would assume that chainsaw do have motor and pumps that runs.   

[Freelander]

Oh yes, the PC (And Web) programmers view that RAM is infinite, and that only crashing once a month is reliable  .

I also love that javascript (Spit!) does not let you do proper networking, in particular it seems you cannot listen to a UDP port, and multicast is 'interesting' very annoying when you have something like audio metering data that you want on a devices web page. Would generating arbitrary TCP packets really have been too much to ask?

Everyone should start by being required to write "Elite" on an 8 bit 1MHz 6502 with 48kB of RAM (Including the frame buffer).

Regards, Dan.

Hi Dan,
Unless I am mistaken, (Quite possibly  ), then Elite was written with 32K ram including video ram. Wasn't the 'frame buffer' (Shadow) only on the post model A / B units ?
Elite was introduced on the Model B (cassette) without the shadow ram afaik.
 

[HalFET]

and introduced that fancy new framework!

Ah, you work with "web programmers" too .

Funny how the frigging web site on an embedded device ends up using more code space then the program that does whatever the thing was really intended to do (And how when you point out that the result needs an I7 with modern gamer graphics to render properly, they cannot explain where the time goes).

Regards, Dan.

Yeah, you also really notice it on mobile phones. They become slower every year because they add more and more abstraction layers and bloated code in between. I'd say Android is a prime example of how to not build mobile software.

[Marco]

The 911 one is just government stupidity and byzantine contracting. If they had an operation centre with operators knowledgeable about all their systems they would have switched over manually within a minute even with the completely bullshit absence of an automated alarm (they should have an independent program running to check whether calls are routed, and on top of that simply no call being routed for a couple of seconds should trip a sanity check for a human to check things out).

[MT]

... well that's what I think. Now read this:

https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/

Get ready for self-crashing cars & self-employing robots. 

would you consider ST generated HAL based code a contributor to future disasters?

[Berni]

Yeah, you also really notice it on mobile phones. They become slower every year because they add more and more abstraction layers and bloated code in between. I'd say Android is a prime example of how to not build mobile software.

Microsoft actually set a good example of a mobile OS here.

They made a derivative of Windows CE called Windows mobile. Graphically it did kinda remind of Win 98 but it would run perfectly snappy even on 32MB of RAM and a old 200MHz ARM CPU with terrible MIPS/MHz. Did take forever to boot and did sometimes need a reboot every month or so but when it worked it worked great. Native exe programs ran with full performance while it did get support for all the other platforms from back in the day such as Java, .NET, Flash etc. It could do everything. Even included hardware 2D graphics with support for hardware video decode that could allow it to play every popular video format without dropping a frame back when being able to play a mp3 was a selling point of most other phones.

Then the first iPhone was released and Android steam rolled the smartphone market. This made Microsoft panic and dump it to bring out Windows Phone 7 instead. This broke all backwards compatibility as it was a brand new product that is designed to be similar to Android with all the graphical eye candy and bloated features that bring modern much faster ARM CPUs down to a crawl.

[ivaylo]

Being on both sides of the fence the biggest problem is that both disciplines do not cooperate more with eachother. It is not or the HW eng or the SW eng fault if problems arise, stop blaming eachother and take a look in each others kitchen before starting bitchin...

This! Was the latest Spectre vulnerability a hardware or a software f-up? Not passing judgment, asking. With modern devops, micro services, etc. complexity can be handled nicely in the web world actually (few people bother to learn though).

[Berni]

... well that's what I think. Now read this:

https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/

Get ready for self-crashing cars & self-employing robots. 

would you consider ST generated HAL based code a contributor to future disasters?

I had the pleasure to use STs HAL library and yes its horrible.

For example the I2C driver is not capable of making a I2C bus restart sequence! It just does a stop followed by a start instead of real restart. According to the I2C spec this is wrong but 90% of I2C chips still work if you do this while some chips don't. To make things worse the way the HAL library uses the I2C controller means that it wont handle a restart being injected in the middle of the read sequence. As a result to get it to talk to my chip i had to rewrite the entire i2c read and i2c write functions by directly manipulating registers like it used to be in the old days.

It would have taken me less time to write the damn I2C driver from scratch than it has taken me to figure out the HAL library, do stuff with it, debug why my chip is not talking to me, googling ways to make it do the correct i2c read seqence, tweaking the HAL code to try and fix it and in the end giving up and rewriting half the driver on my own anyway.

[donotdespisethesnake]

It's a fascinating topic, and I've been reading articles like this for 30 years since I started professional programming. None of the stuff in the article is new, and it doesn't advance any new solutions. It also doesn't have any new insight into why programming is difficult, or how it could be effectively improved.

What is invariably missing from all the fine words is consideration of the commercial environment. For some organisations with a lot of resources, commercial motivation, and really smart people, they can apply advanced solutions to some specific problems, but that doesn't help all the small run of the mill places where coding takes place. They simply don't have the resources to reengineer how they write software.

Progress in hardware is made because smaller features lead to faster processing, lower power, and lower cost. It's a positive feedback with win,win,win outcome. No one has found any equivalent procedure for software - my conjecture is that none exists. Writing bug free software is possible but it takes more time and money - a negative feedback that is resisted by realities of cost/benefit equation.

Software is stupid

Of course. But most people are stupid, and software only has to be slightly less stupid than people to be useful. ("You don't need to outrun the tiger, only the guy next to you")

It's likely that "self-driving" cars will kill people, but overall that will be safer than letting humans drive.

[tszaboo]

Software is made overly complex over the years, and this is done because features. Features, that are not necessary, which are the bane of reliability. Do you really need to be able to do all those things in software? Do you really need all the APIs the wrappers for the API, the abstraction layer for the wrapper? No. But someone asked for a feature, and it "needs to be done". Do you need to be able to start your Fiat Jeep from your iPhone? No. But they did it anyway, and they did it badly. Are you suprised? It was probably built by a team of 50 engineers, all of them focusing on a small task, connecting the CAN line of the device to the ECU, connecting the ECU to the bluetooth module, running some legacy code written by interns.
I have an error, which would require me to make changes in the linux kernel. I'm not even kidding. There is an I2C device, that I'm using, it has a software reset function, that I need to use for normal operation. When the software reset happens, it doesnt send an acknowledgement to the host, it resets, not finishing the I2C transaction normally. The hosts generates an error message.
You know, what the device is? An LED driver.

So because some weird bullshit requirement to be able to blink LEDs, I would need to change stuff in the linux kernel to be able to suppress error messages. Instead of fixing the code (and probably breaking someone else's code) how about getting sane requirements?

There is a system with 4 requirements. Like this button does this, that button does that, this switch is for safety, it stops movement. Each function has a piece of code, which is simple and works fine. The 4 piece of code has 6 ways of effecting each other. Just draw a graph for it. When you add a 5th option, the number of these connections grows to 10. Something which we take granted, like a TPC-IP stack has billions of these connections, possibilities, that one part of the code messing up another part. Programmers can't keep track of it? I'm not surprised.

[IanMacdonald]

Part of the problem is software writers insisting on continuing to use programming languages which went past their sell-by date even before Windows XP was thought of. Yet, at the same time they berate us for using 'old and insecure' software! The hypocrisy of this beggars belief. 

http://iwrconsultancy.co.uk/blog/badlanguage

[donotdespisethesnake]

Software is made overly complex over the years, and this is done because features. Features, that are not necessary, which are the bane of reliability.

The interesting thing is that ICs are far more complex than they used to be, e.g. the first pong game was a bunch of TTL logic gates. Now I can do all of that plus a lot more with a single IC, AND have hundreds of logic cells left over. The modern IC is cheaper, faster and smaller than the old TTL. (No run time software involved).

So the key question is, why is increased complexity OK for hardware, but not software?

[paulca]

The original articles focuses a little too much on non-programmers and non-business analysts cherry picking examples such as WYSIWYG and Photoshop.  Woo hoo, pretty pictures, now I can visualize my code, I'm great.

Maybe they should go and program in MIT Scratch and feel all warm and fluffy.

You try created a billing system for an energy retailer.  You receive requirements through about 3 different channels to about 3 different people in your team.  The customer doesn't even understand their current business processes nor what they want their new ones to be.  You fight valiantly trying to get to the details out of them, trying desperately to explain when requirements actually conflict, but they run around you and the code gets done by a junior engineer anyway.

6 months later they are complaining the system is unstable.

Of course it fucking is!

[donotdespisethesnake]

Part of the problem is software writers insisting on continuing to use programming languages which went past their sell-by date even before Windows XP was thought of. Yet, at the same time they berate us for using 'old and insecure' software! The hypocrisy of this beggars belief. 

http://iwrconsultancy.co.uk/blog/badlanguage

I think that is over played, I have seen buffer overrun errors in Pascal code. It would help if languages were technically better, but languages and programming techniques haven't really improved over 30 years. The biggest change in software is we have much faster hardware, compiling and debugging is orders of magnitude faster.

However, it still misses the point. Programming is done in a commercial environment, not an academic one. Features and price sell products, reliability doesn't.

If increased software reliability coincided with lower cost and faster development, companies would be on it like a shot. But all known techniques to improve software reliability require more skilled engineers, longer project times, higher product cost. Companies will happily ditch all that for cheap and quick, unless the customer can be charged a lot more, e.g. defense, aviation.  For consumer products low cost is mandatory.

In terms of market demands, automotive sits between consumer and safety critical, so it will be interesting to see how it plays out. Clearly in the Toyota case they didn't pay enough attention to safety, but many other manufacturers are treading the same line between safety, low cost and inflexible development timescales.

[paulca]

TLA+... from the article.  Lets look at one line of it.

Code: [Select]

Spec == Init /\ [][Tick]_<<clock>> /\ WF_<<clock>>(Tick)

 

[MattSR]

I couldn’t agree more on this point. These types of programmers have no concept whatsoever of the hardware they are coding for.

Oh yes, the PC (And Web) programmers view that RAM is infinite, and that only crashing once a month is reliable  .