Software is stupid, programmers are overpaid poets.

[donotdespisethesnake]

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.

^^ This! It's the same nearly everywhere I have worked.

Even if I could write a formal spec for the design, different product managers submit conflicting requirements. None of them would understand the spec. Even if the spec is written in plain english, getting them to read, understand and sign off is hard work. Regardless of what is agree, the requirements will change multiple time through development.

I then find the engineers designated TBA1 and TBA2 are never employed, so the dev team has to develop the product with less members than planned, who also spend half the time supporting the previous project that over ran. If we refused to engage the project, it would be simply passed to another department who hires a bunch of cheap coders fresh from college, or more likely outsource to someone who does the same, except charges 5 times as much for a worse result.

Saying that "if only programmers used a better programming language, products would be so much better" is kinda like saying "if only all countries used the same currency, then no one would be poor and go hungry".

[paulca]

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

No matter what language you use, memory is memory, pointers are pointers, offsets and vectors are offsets and vectors.  All different languages do is provide a different abstraction of them.  All languages are code themselves.  All code has bugs.

If you try and put an elephant into a cat box it will overflow.  It doesn't matter if the elephant speaks English or Pascal.

Enforced boundary checks?  Great, so your software crashes with a boundary check message instead of overrunning the buffer.  An improvement, but still ... your program crashed.

Buffer overrun issues at 99% laziness or sloppiness.

As someone above mentioned, software is written in a commercial environment.  Often "the business" puts pressure on the software teams to get MORE functionality.  The software team screams of technical debt, such as "Checking the junior engineer's buffer boundary checks" and "Code reviews", updating unit tests, bolstering the integration tests.  The business hears, "We want to burn more time, spend more money and not make anything we can sell".

If customers spoke code and could provide their requirements specified as critically black and white and the business / account / project managers were the programmers things would happen differently.

Today the idea is to accept all these failings and to develop in fast iterative cycles.  Listen to the customer, try your best to produce something that matches it in 2 weeks, show it to the customer.  Take away the feedback, improve or rewrite the software, repeat.

The trouble is the business / money managers again get involved and don't seem to understand the "iterative" bit.  we are back to the standard.... "If you show a business manager a PoC they tick the DONE box and ask you to move on."

[IanMacdonald]

"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."

I was referring more to security issues, but yes, any code can contain bugs. It's just that the security flaws have more serious consequences then the odd bluescreen or two.

You could create a buffer overflow in a DLL call from Pascal, in fact you can do that in any language because the problem there is that the system DLL call mechanism itself is vulnerable. However, you cannot create a buffer overflow vuln in native Pascal code without doing really silly things. It is also possible to create a buffer overflow in Fortran, but again, only by doing daft things.  In C, it's a question of a moment's carelessness. 

[paulca]

I was referring more to security issues, but yes, any code can contain bugs. It's just that the security flaws have more serious consequences then the odd bluescreen or two.

However, as complex as things are, what do you think the chances of boundary check enforcement being exploited?

[filssavi]

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.

^^ This! It's the same nearly everywhere I have worked.

Even if I could write a formal spec for the design, different product managers submit conflicting requirements. None of them would understand the spec. Even if the spec is written in plain english, getting them to read, understand and sign off is hard work. Regardless of what is agree, the requirements will change multiple time through development.

I then find the engineers designated TBA1 and TBA2 are never employed, so the dev team has to develop the product with less members than planned, who also spend half the time supporting the previous project that over ran. If we refused to engage the project, it would be simply passed to another department who hires a bunch of cheap coders fresh from college, or more likely outsource to someone who does the same, except charges 5 times as much for a worse result.

Saying that "if only programmers used a better programming language, products would be so much better" is kinda like saying "if only all countries used the same currency, then no one would be poor and go hungry".

This has absolutely nothing to do with software it is the same thing in hardware, most of the times, the client has only a vague idea of what it want, it’s your job as a engineer to translate the hand-waivy explanations in specifications that can be implemented cleanly, after all if they had the expertise to define a detailed spec they could as well implement the thing themselves

Case and point, the guy next to me is working with a worldwide famous high end car maker and he is modelling components they had made to specs by a big, world famous automotive power electronics manufacturer the most time has been spent tritino to understand the specs of the object, since the carmaker (client) had absolutely no idea whatsoever

I think that the problem is entirely due to the general business model of the software companies

[Kjelt]

With hardware the product owners and managers understand that changing it after it has been built is very expensive. They still don't get it that in the meantime it is just as costly to change software esp when it involves redesign, architecture change because suddenly some product owner woke up in the middle of the night with this great new selling feature that all customers want, one problem it was not foreseen at design time, no-one knows how long it will take to implement without a good analysis and still "stop everything" this new feature has to be made now and done in two weeks.
There are new ways of working in SW country for instance we work Scaled Agile framework. We plan for 6 sprints, 12 weeks, but after 4 weeks the planning is already completely obsolete. That is how bad a SW environment can be, very dynamic.

With hardware analogy it would mean someone would look at your finished hardware pcb being a DAC and tell you to change for instance the DAC because the other manufacturers part is 10% cheaper, can you finish at the end of the week? It would ruin the whole design, you have to redo many parts.

[tggzzz]

Enforced boundary checks?  Great, so your software crashes with a boundary check message instead of overrunning the buffer.  An improvement, but still ... your program crashed.

In those cases crashing is better than not crashing.

If you are prepared to accept incorrect results, then I can make any program significantly smaller and faster.

[bd139]

Indeed. I tend to scatter my code liberally with assertions. Just doing a quick grep on the codebase in front of me we have 190,000 assertions.  The name of the game is to not trigger any of them. If you do trigger one instead of leaving a steaming core dump it bins the thread, writes out a unique error code and logs the stack and an assertion message which is very easy to trace. Also every message has a correlation ID so we can trace the execution through all layers including storage then replay offline.

Crashing is good. Design your software to survive crashes not design your software to not crash.

[Jeroen3]

With hardware the product owners and managers understand that changing it after it has been built is very expensive. They still don't get it that in the meantime it is just as costly to change software esp when it involves redesign, architecture change because suddenly some product owner woke up in the middle of the night with this great new selling feature that all customers want, one problem it was not foreseen at design time, no-one knows how long it will take to implement without a good analysis and still "stop everything" this new feature has to be made now and done in two weeks.
There are new ways of working in SW country for instance we work Scaled Agile framework. We plan for 6 sprints, 12 weeks, but after 4 weeks the planning is already completely obsolete. That is how bad a SW environment can be, very dynamic.

When you start looking at the details of what you're actually supposed to build with the tools you have, a completely new forest little things blocks the road. We fall for this every time.

[Marco]

Buffer overrun issues at 99% laziness or sloppiness.

Unless you can create better humans the use of languages which makes bugs created by lazy and sloppy humans harder to exploit would be the optimal solution in 99% of cases. If we hadn't wasted multiple decades listening to C programmers pretending that laziness and sloppiness could be overcome by just layering on more procedure.

If all the effort spend on C++ would have been diverted into creating more efficient memory safe languages we'd have avoided a lot of buffer overflow exploits. Also SQL should have been designated a WMD 20 years ago.

[vodka]

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.

^^ This! It's the same nearly everywhere I have worked.

Even if I could write a formal spec for the design, different product managers submit conflicting requirements. None of them would understand the spec. Even if the spec is written in plain english, getting them to read, understand and sign off is hard work. Regardless of what is agree, the requirements will change multiple time through development.

I then find the engineers designated TBA1 and TBA2 are never employed, so the dev team has to develop the product with less members than planned, who also spend half the time supporting the previous project that over ran. If we refused to engage the project, it would be simply passed to another department who hires a bunch of cheap coders fresh from college, or more likely outsource to someone who does the same, except charges 5 times as much for a worse result.

Saying that "if only programmers used a better programming language, products would be so much better" is kinda like saying "if only all countries used the same currency, then no one would be poor and go hungry".

This has absolutely nothing to do with software it is the same thing in hardware, most of the times, the client has only a vague idea of what it want, it’s your job as a engineer to translate the hand-waivy explanations in specifications that can be implemented cleanly, after all if they had the expertise to define a detailed spec they could as well implement the thing themselves

Case and point, the guy next to me is working with a worldwide famous high end car maker and he is modelling components they had made to specs by a big, world famous automotive power electronics manufacturer the most time has been spent tritino to understand the specs of the object, since the carmaker (client) had absolutely no idea whatsoever

I think that the problem is entirely due to the general business model of the software companies

Those problems between "The  Customers" and "The Analysts" are very old. At theory, the customer have to explain the business model, as working and the fails to analyst. Now ,i think that the 90% the customers are bosses or manager who have never worked on the subordinates level,therefore the bosses don't know like work the system. Furthermore, if the analyst neither doesn't know like work customer's system and he is that says "all yes" to customer. The project will redesign 1000 times.

Wherefore, the good programmers have to leave an open design for modificating the source code without have to rewrite it all.

[MT]

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.

No wonder cost of car today is 72% electronics related, according to reputable auto industry research papers.

[janoc]

you will have the largest DDOS botnet in the world - just pay a few bucks to an ad network to deliver your code as ads on some high profile websites.

That surely is what firewall rules exist to prevent?

Since when are firewall rules responsible for ad blocking?

End of the day I don't really care what the JS does within its sandbox, but there are more appropriate places to filter network frames then at the edge of the sandbox, and those places are generally more usefully configurable.

I would get less annoyed by this sort of thing if I was not always being told by our web devs that web based 'apps' were the future, when they clearly cannot do basic things that I would expect of a general purpose machine.

Sorry but you sincerely expect a lay user to be able to configure their firewall correctly so they don't get compromised by malware deployed on mass scale via web browsers??

 

I guess you forgot the mass ransomware and virus infections - which mostly spread via drive-by downloads and exploits in browsers these days.

Javascript in a browser has no business generating arbitrary network packets. If you need that, your server layer should take care of it and deliver you the result e.g. over a websocket.

I am no fan of webapps or using HTML for UI (even less on embedded!) but if someone is going to do it, then please learn about the dangers first! Otherwise you (and your gadget) are risking to end up as yet another exhibit on the InternetOfShit Twitter stream.

I am fed up with networked gizmos designed by people with no clue about basic information security, the main thing being that "it works" and we have shipped it, screw the end user.

[paulca]

Javascript in a browser has no business generating arbitrary network packets. If you need that, your server layer should take care of it and deliver you the result e.g. over a websocket.

I hate Javascript with a passion.  It's a rubbish language that was never intended for it's purpose, based on out of date techniques that grew warts, heads, arms and legs in all different directions and has only recently be 'tamed' in any way at all.  Mostly due to VERY heavy compatibility frameworks behind things like Angular and React.

It should have remained a sandboxed, interrupted automation framework for making text flash and scroll.  We should have come up with something better rather than struggling on with it.

I'm actually fairly angry that spectre and meltdown have javascript as a vector.  That's just dumb.  who let it out of the browser interrupter and why?  Don't start me on the f'ing script kiddies getting on the server with Node JS either.  Piss off back to playing with "Poke your boss in the eye" apps and learn a real language if you want to play with the real toys.

Though I do know why unfortunately.  Business and money.  Why put 8 servers in your rack and generate HTML when you can put 2 servers in your rack and send JSON, let the browser do all the hard work and use clients electricity and CPU.

[tszaboo]

No wonder cost of car today is 72% electronics related, according to reputable auto industry research papers.

And that is the part, which keeps on working. At least I never hear that in the service, they need to replace the ECU and the cabling and the software after 100Km, because it wore out. It is always some mechanical fluidy plastic thingy which rotates and breaks because you dear using it.

[Vtile]

No wonder cost of car today is 72% electronics related, according to reputable auto industry research papers.

And that is the part, which keeps on working. At least I never hear that in the service, they need to replace the ECU and the cabling and the software after 100Km, because it wore out. It is always some mechanical fluidy plastic thingy which rotates and breaks because you dear using it.

Nah. Moisture here and there, lots of faults features in electronic cars. Door harnesses are the worst, second to the "automatic" pressure valves in tyres.

Obviously this topic should be splitted to realtime software and software. Realtime software have many times tentacles outside the CPU & memory structure in form of realworld loops backs.

[paulca]

Wherefore, the good programmers have to leave an open design for modificating the source code without have to rewrite it all.

Yes.  This leads to the current mess we called Enterprise Java. 

Design by "But what if..."

"Design a piece of software to help someone walk."
"But what if they have only 1 leg?"
"What if they have 3 legs?"
"What if someone has no legs?"
"Should we support cats too?"
"Well if we are supporting cats, why not dogs?"
"Gerbals?"
"What about wheels?"

2 years later what should have been done in a week is STILL in development.  The lead engineer and his favourite side kick are the only ones who understand WTF is going on in a HUGE MASSIVE death star of a frameworked application.  Thousands of abstract classes, each with single implementations below interfaces.

2 years later the customer says, "We have client who uses his arms to walk."

BOOOOM!!!!!

Now the 2 week application would take about another week to change to support 2 arms.  The "Death Star^TM" takes another 2 years.

The people who have to support it in the wild leave the company because it's just too difficult and they can't stand working with it.

It's consultancy 101 if you are developing an application for someone else that you can walk away from, being paid by the day, make it as complex as possible, throw the kitchen sink and the full family wedding gift list at it.  Make sure only you and your team understand it.  Charge by the day.

This, currently is my nightmare and it's happening to me all over again.  My solution is to follow the agile process and design underneath them, get the damn job done, evaluate and move forward while they construct their Death Star.

[Berni]

Unclear and ever changing specifications are indeed the worst in programming.

You can try to make the code simple and to the point but then when they ask for a new killer feature means that a great deal of code has to be rewritten to support it. If you make the code broad and universal to cover lots and lots of "what if" scenarios then the code becomes a huge tangled mess where everything in some convoluted way depends on everything else. Now you are digging trough all that crap to find that magical function that can do the feature, only to find that that function is sort of half broken and you need to waste even more time trying to debug why it doesn't work.

[Kjelt]

Todays Dilbert is ontopic

http://www.dilbert.com/strip/2018-01-23

[tggzzz]

Unclear and ever changing specifications are indeed the worst in programming.

Too limited: change "programming" to just about anything you like. Examples: hardware, lawmaking, renovating kitchens, etc etc etc

[GeorgeOfTheJungle]

I hate Javascript with a passion.  It's a rubbish language that was never intended for it's purpose, based on out of date techniques that grew warts, heads, arms and legs in all different directions and has only recently be 'tamed' in any way at all.  Mostly due to VERY heavy compatibility frameworks behind things like Angular and React.

You're talking complete bollocks. And again, Javascript != DOM.

[paulca]

I hate Javascript with a passion.  It's a rubbish language that was never intended for it's purpose, based on out of date techniques that grew warts, heads, arms and legs in all different directions and has only recently be 'tamed' in any way at all.  Mostly due to VERY heavy compatibility frameworks behind things like Angular and React.

You're talking complete bollocks. And again, Javascript != DOM.

Well thank you for that elaborated correction to my opinion.  I am perfectly aware of what DOM is thank you and I'm not sure where I said Javascript == DOM.

[GeorgeOfTheJungle]

You're talking complete bollocks. And again, Javascript != DOM.

Well thank you for that elaborated correction to my opinion.  I am perfectly aware of what DOM is thank you and I'm not sure where I said Javascript == DOM.

Ok, sorry, if that was rude I apologize. There are despicable javascript fanboys and there are too, despicable javascript haters (*). Let's leave it at that 

I'm not a fanboy but I've had to learn JS and write many tens of thousands of LOCs in Javascript and it's actually a pretty good language, Javascript, not the DOM (see "An Inconvenient API - The Theory of the DOM" @youtube).

(*) Most of which confuse the DOM with JS, and/or can't grasp why JS is no C nor JAVA: different scoping rules, closures, prototypal inheritance, no classes, asynchronous/evented execution, etc.

[paulca]

(*) Most of which confuse the DOM with JS, and/or can't grasp why JS is no C nor JAVA: different scoping rules, closures, prototypal inheritance, no classes, asynchronous/evented execution, etc.

We can disagree on the language.  I worked with developing Javascripts frontends for several years in the past and I still hate it.

It's really scheme or closure with scheme/closure crossed out and Java written in as a marketing ploy.  Until the ECMA standards came in it wasn't really a language at all, it was a collection of hacks each one different in each browser.   In part it STILL is.  It's just that we have frameworks today that hide this and work around the browser implementation oddities.

It's dynamic typing is fairly retarded and sometimes extremely irritating.  The scope is bonkers.  Everything seems to be a function that takes a function as an argument and returns a function that takes a function as an argument.  Recursion and callback-tastic.  It's object orientation is just broken.

The only good thing that came out of Javascript was JSON, which thankfully shut the XML fan boys up enough that we managed to get away from slow, verbose, cumbersome DOM structures and immensely inefficient parsing.

[bd139]

JSON is shit. Bad numeric types, no reliable schema implementation, terrible Unicode problems. Nothing to like. It’s 2017’s CSV that fell out of the JavaScript crack pipe.

BSON fixes some of that shit but just use protobufs or something instead.

XML is one of those things that will outlive us all and be determined that it was a good idea after all but not until, like all human progress, many things have died first.