Software is stupid, programmers are overpaid poets.

[GeorgeOfTheJungle]

What about PayPal? They use Java server side.

https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/

Meanwhile Facebook, Microsoft and Google all have their own version of typed Javascript (with a few more out there).

Typescript and etc. are good for (ex-java) programmers that can't live without ctrl-space but in the end it still compiles to javascript: https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js

[paulca]

One of the main problems in the industry is lack of talent.

I don't mean that sarcastically either.  Literally lack of talent.  In the UK schools, primary and high school have completely trashed the reputation of "IT" as a career by reducing it down to "ICT Skills" which is then implemented by teaching kids how to use Microsoft Office.  99% of kid immediately go "Sod that I'm not doing a career in IT!  No way!"

After 20 or so years of this the number of IT graduates coming out of universities has diminished while the demand for software continues to increase.  The net result is that companies I have worked for now recruit via transfer courses to take people with any degree (or no degree at all), put them through a 6-12 week "Academy" and plonk them into a programming or analyst career.

Worse is that the senior engineers are very often not given enough time or resources to continue their training.

So dodgy, miss guided, naive code becomes the norm and people like myself simply don't have the time to review, rewrite and education to correct it.

If you want an idea of how bad it gets just look at the code that floats are EE forums.  (Hell I'm guilty of it, the difference is understand my code is "PoC" at best).  A lot of people believe the sketch they download from AdaFruit forums and works constitutes completed code.  In that context we need to do our due duty and remind people that that level of coding is the equivalent of a breadboard project.  The real project will expand a lot once proper error handling, refactoring for test-ability etc. etc. id conducted.  In a similar way to how an electronics project expands as it moves from a breadboard hacked test to a product.

[tggzzz]

One of the main problems in the industry is lack of talent.

I don't mean that sarcastically either.  Literally lack of talent.  In the UK schools, primary and high school have completely trashed the reputation of "IT" as a career by reducing it down to "ICT Skills" which is then implemented by teaching kids how to use Microsoft Office.  99% of kid immediately go "Sod that I'm not doing a career in IT!  No way!"

After 20 or so years of this the number of IT graduates coming out of universities has diminished while the demand for software continues to increase.  The net result is that companies I have worked for now recruit via transfer courses to take people with any degree (or no degree at all), put them through a 6-12 week "Academy" and plonk them into a programming or analyst career.

Worse is that the senior engineers are very often not given enough time or resources to continue their training.

So dodgy, miss guided, naive code becomes the norm and people like myself simply don't have the time to review, rewrite and education to correct it.

You've missed one other very important factor. Recruitment agents and HR-droids actively regard people over 35 as PSBD (past sell by date).

[Kjelt]

And still it is more complex since even good experienced programmers have their own WOW , their own coding styles and guidelines which are not always (pun intended) compatible.
Very simple example:

Some SW engineers write defensive code, in the function they start verifying the input parameters for validity and even output parameters like pointers to buffers.

Other SW engineers or a "guru" like uncle Bob say don't do this, it makes the function unreadable hard to understand and messes up lean clean coding. Their point is that the test framework should prevent that these functions are called with incorrect parameters.

So who is right? I think both or none it depends on the company. In my company we have seperated the task of writing the testframework from implementing the code, you bet that in this case where there is no hard binding in time between the testframework and the implementation uncle Bobs WOW might fail miserably. That is why uncle Bob says that the SW engineer should first write the testframework himself, when finished start coding. That sounds expensive, the SW engineer should write at least double the code and probably in embedded cases in two different languages.

Only a simple example and in practice there are tens of this sort dilemmas that easily could ruin your product.

[@rt]

The programmers would know best what their software can and cannot do, but probably like being paid.
I think just about every new technology is rushed in too fast.

Spaghetti thing makers are a prime example.
It will be another ten years before I'd even look at a spaghetti thing maker.

[tggzzz]

Spaghetti thing makers are a prime example.
It will be another ten years before I'd even look at a spaghetti thing maker.

The analogy between software tools and kitchen tools isn't a bad analogy. Good questions:

• can I do new thing Y with new tool X?
• can I do new thing Y with the tools I currently have?
• if not, what else could I use to do new thing Y?
• does new tool X interwork with my existing experience and tools, or am I having to start from scratch?
• is there a sustainable ecosystem around new tool X?
• what happens when tool X's manufacturer stops?

Most new tools X fail at least one of those tests.

Most new kitchen implements also fail the "does it take longer to clean it than the time saved using it?" test.

[Kjelt]

Spaghetti thing makers are a prime example.

That reminds me 
Having a seperate research department that creates prototypes, mostly PhD's and academic persons that are excellent in creativity and making fast working prototypes and that is what they are paid for.
Then the managers see the prototype demonstration and think that it is ready for production, it works so the rest is just a month work or something like that.

Yeah right these great minds are good in building something fast which has its value and grant them that, but they have zero knowledge of writing good software that is production ready.
If you are lucky the software handles all sunny day scenarios but that is it. It works for a couple of hours than has to be reset and if you look at the software you practically have to start from scratch. Algorythms are usually ok'ish but the architecture, lack of design (patterns) and spaghetti code where exceptions are unhandled is disastrous.

Try to explain management that the demo they saw is a rust bucket with a thin golden layer on top which works for a day at most , and to be able to put it in production the whole chassis has to redesigned.

[Marco]

https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/

That predates the widespread adoption of typed Javascript, more importantly though they seem to have moved back.

[bd139]

Can I stretch the kitchen analogy further because I think it's a really good one. This turn out a bit longer than expected but this is the shit that goes around in my head all day while facepalming at failing and miserably shit software teams:

I am quite adept with a single Santoku knife I paid a £20 for, to the point I can usually cook ANY meal with just that, a table fork and a couple of pans or trays efficiently, reliably and quickly.  I've had it for 20 years. Unfortunately, sometimes the wife comes along with the garlic crusher, the mixer, the strange peeling devices, the odd shaped single use tins, every frying pan, dispensers etc.  She does this because she saw someone on television doing it and felt that's how she should be doing it. She was inspired to try these new ways of doing things to solve the same problems she had before. There is no rational reason that the solution is any better. The result, as tggzzz so elegantly put it, is nothing but more washing up.

A big problem with technical leads is their almost religious following of ideologies which are promoted by the tech equivalents of Nigella Lawson and Jamie Oliver etc. The promoters of these ideologies have unstoppable momentum via conferences etc which result in the ideologies being adopted without rational analysis. When you go to these conferences, they are full of people looking for an ideology as well. This bolsters the new way of thinking even further. The next thing your tech leaders do is come back as freshly converted Jehovas Witnesses or something even worse like DDD or devops proponents.

Then this leads to the question of discipline. How do you get 50 people to conform to a certain ideology that they really don't actually give a fuck about? Well it turns out that someone has this wonderful tool which makes it all good. So they buy 50 fucking garlic crushers and make them crush garlic all day. Then you find that the things get jammed up with shit, so you have to hire someone to unclog the crushers. This poor team of uncloggers feels unfulfilled and starts to bail out. Management are annoyed that their entire delivery cycle is being ruined so start putting some pressure on the technical leads. Then someone else comes along with another ideology which conveniently solves this problem. This ideology is getting the end users to unclog their own garlic crushers. Now the fresh uncloggers don't have time to do this because they're already expected to be churning out crushed garlic pretty quickly because of the management pressure and now they have to learn how to unclog the crushers. At the end of the day, velocity and quality decline, no one gives a fuck and everyone leaves to work for a company that has apathetic management who don't want you to crush garlic all day and never go to conferences, because that would actually create them more work.

And that's how you fuck up a software company.

Don't buy into an ideology, stay away from complex tools, keep it simple, be lazy, use decisive small tools.

Personally my favourite stack is: centos, vim, valgrind, gdb, make, svn and bugger all else.

[MT]

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.

Nope, just gently moist or flood a car (Texas/Flordia/Djungle/damp costal regions) and you get a car that's going to show all kinds if electrical problems including complete rewiring and ECU replacement. My current car have shown
way more electrical failures then mechanical and the mechanical i can fix my self.

Mind you the trend of autonomus cars i recall was not initiated by auto industry rather from the IT EE folks , they
like Philips deliberately creates a imaginary problem that needs a imaginary fix (personal kitchen 19.99usd baking machine). What do bakers think about Philips?

When software are able to fix outback road driving (Siberia etc) then just inner city then we can talk about global automatically driving, if its even desirably.

[@rt]

I needed a washer once, to insulate a standoff in the middle of the washer, from the conductor on the outside of the washer.
It was to be clear acrylic with a silicon layer each side of the washer, and I offered to pay a tidy sum for something so simple.

The first try was a fellow proud of his spaghetti creation. It was laughable, but wouldn’t do any damage to try it.

[IanMacdonald]

Just met a case of this. Set up a high value banking transaction which involved entering a 20-digit number and other details with great care. Was then told I had to wait for a mobile phone message for two-factor auuthentication. Only, this is a new feature and they haven't told users to give them a mobile number yet.

So, went to the personal details page and tried to enter a number. Was told that the number could not be accepted because the existing number was {blank}. Well, yes of course it is because..

This is a typical syndrome with programmers. They simply have no real world commonsense. They can write 20,000 lines of utter gibberish, but can't think through even a simple real-world action. If they had to tie their own shoelaces they'd do so first and then try to put the shoes on. 

Another big problem with software these days, especially browser software, if there's any problem at all, PHUT! and everything you've entered is gone. In the old days they used to remind us to back up regularly. Now, the systems provide no way of backing up so as soon as there's a glitch you lose the data.

[bd139]

Capital One did that recently. They introduced 2FA and fucked it right up. 

[tggzzz]

Then the managers see the prototype demonstration and think that it is ready for production, it works so the rest is just a month work or something like that.

When Java Swing GUI programs were a hot thing, there was a very useful "skin" that could be used in such circumstances: "napkin skin".

Its purpose was to look like something scrawled on the back of a napkin, so that it signalled "prototype". All the GUI widgets worked as you would expect, but the background was crumpled paper and the text was handwriting.

[tggzzz]

Just met a case of this. Set up a high value banking transaction which involved entering a 20-digit number and other details with great care. Was then told I had to wait for a mobile phone message for two-factor auuthentication. Only, this is a new feature and they haven't told users to give them a mobile number yet.

So, went to the personal details page and tried to enter a number. Was told that the number could not be accepted because the existing number was {blank}. Well, yes of course it is because..

This is a typical syndrome with programmers. They simply have no real world commonsense. They can write 20,000 lines of utter gibberish, but can't think through even a simple real-world action. If they had to tie their own shoelaces they'd do so first and then try to put the shoes on.

"FSMs? What are they? Oh yes, I seem to remember something about them being used in compilers."

[bd139]

That's even pushing it a bit. Most people glaze over if you mention any algorithms. They are the same numpties who think LINQ is the best thing ever, then it hits production and they didn't realise that it's just a fancy iterator implementation and doesn't scale as well as it did when they tried it on 6 objects in test.

Also I added a simple hand coded state machine for parsing some streaming data once and was asked to remove it because no one understood it. I was told to replace it with a big regular expression.  Which would be fine but the fucking thing was not a regular language...

Aaagghghghgh thank fuck I work in an office graced with more than one copy of the dragon book now.

[paulca]

This is a typical syndrome with programmers. They simply have no real world commonsense. They can write 20,000 lines of utter gibberish, but can't think through even a simple real-world action. If they had to tie their own shoelaces they'd do so first and then try to put the shoes on. 

Ian I think part of your perception is that you believe it's one programmer or one team.  It's most likely a dozen different teams in a handful of different countries.

Team one has been told to enforce 2 factor authentication in the REST teir.
Team two has been told to implement the web UI components for it.
Another team has implemented the SMS gateway.
Another team has done the data access layer.
Another team has done the database changes and stored procedures.
Another team manages the interconnect messaging bus.
Another team has been told to make phone numbers mandatory on another part of the UI
Yet another team has tested part of it.
Yet another team has tested another part of it.
Finally another team did pen testing and vun testing and proposed changes back to all of the teams above.
Management and business didn't factor in the time to fix these security concerns and rushed them through, probably asking people to work until 11pm for a week!

All of them are working with partially complete requirements and test plans written by partially incompetent BAs.   The Project managers and scrum masters who job it is to make sure changes synchronize across all the teams for a release are probably barely sentient.

So most likely the programmers all did what they were informed they were supposed to and only had a limited view of one or more parts of the overall solution.  I can guarantee you that 90% of them never, ever looked at the public version of the website.

Someone somewhere dropped a ball, probably in final UAT testing.  Or maybe it was a deployment issue.

With my lead developer hat on, I would guess what has happened is that the requirement for the two factor stated:

WHEN customer.PhoneNumber is NOT NULL or ""

But previously they had used the value {blank} in place of NOT NULL or "" for a version back in the past.

Nobody remembered this across all the teams and nobody tested it and ... BANG.

[dryjoints]

Software:

> Nothing set in stone (except stupidity, perhaps).
> What works one week, will have been "upgraded" or "deprecated" the next, breaking your machine.
> You cannot SEE what is broken, or smell that it's broken, or feel it getting hot.
> You spend your entire working life staring at a screen or ten.
> There is NOTHING physical to present with pride to show a family member or colleague; software is - at best - abstract, meaningless gibberish to the average mortal.

Hardware:

> Subject to the unchanging laws of physics, constants that are rock solid and can be measured, logged and relied upon ALWAYS.
> You can see what's broken through symptoms, dry joints, burnt out components etc.
> You can grab your latest creation, take it home and show it off to your family; "I just made this!" beaming with delight.

[paulca]

> You can grab your latest creation, take it home and show it off to your family; "I just made this!" beaming with delight.

Until in the middle of the night it develops a fault induced by a mistake in a datasheet you trusted and sets fire to your dog, burning the rest of the house down and killing your parents... and your dog.  You spend the next 10 years learning to program software from prison while serving a scentence for involuntary man slaughter

[tggzzz]

Aaagghghghgh thank fuck I work in an office graced with more than one copy of the dragon book now.

At university I decided I would never (1) have anything to do with compilers, and (2) ditto databases.

I manged (1), and my involvement with (2) was to throw the damn thing out and replace it with a replicated distributed in-memory key-value store. Much more efficient

[bd139]

throw the damn thing out and replace it with a replicated distributed in-memory key-value store. Much more efficient

Music to my ears. We use Riak for a lot of stuff which fits that criteria. Actually we ripped off a lot of our architecture from the NHS's spine2 project 

Levering the organisation off relational databases is hard though so there's a ton of SQL Server instances still left.

Only problem is Basho has gone down the shitter so we're going to have to hire a couple of good Erlang guys in to look after it. They're still cheaper TCO than one SQL server instance on the scale we need.

[tggzzz]

Hardware:
> Subject to the unchanging laws of physics, constants that are rock solid and can be measured, logged and relied upon ALWAYS.

OK, what's the e_r of your FR4 PCB? I take it you haven't designed+implemented any modern logic circuits or microwave filters etc.

Or, for that matter, what's the speed of light?

> You can see what's broken through symptoms, dry joints, burnt out components etc.

Sometimes, as with my latest toy (a Tek 485),  the only symptom is "the PSU is clicking on/off". I hope it ends up being merely an invisibly short circuit tant cap, or an invisibly high ESR cap.

> You can grab your latest creation, take it home and show it off to your family; "I just made this!" beaming with delight.

True.

[paulca]

> You can grab your latest creation, take it home and show it off to your family; "I just made this!" beaming with delight.

Software:
> You can upload it to the internet, announce it on a mailing list and the whole world can see it and you become a household name and a millionaire in a week.

Linus Torvalds
Mark Zuckerberg
Bill gates
et. al.

[bd139]

Sometimes goes a bit wrong though: https://en.wikipedia.org/wiki/TempleOS

[Vtile]

Sometimes goes a bit wrong though: https://en.wikipedia.org/wiki/TempleOS

At least teh programming language which were used to create the TempleOS is spot on as HolyC. The holy language of the ceremonial programming tasks, the almighty software geekery.