For Gene

[aquaduct]

Compexity

[Dub]

Jun 12, 2022 22:56:57 GMT -5 aquaduct said:

Compexity

That link resolves to: acoustictalk.proboards.com/thread/58904/gene

It’s like the old rude joke about the business card that asks “How do you keep a [target ethnic group member] busy all day? See other side.” Of course the other side of the card is exactly the same.

[gbacklin]

[gbacklin]

[millring]

[aquaduct]

Ahhh, I see what happened here.......

nolanlawson.com/2022/06/09/the-collapse-of-complex-software/

[gbacklin]

Jun 13, 2022 5:38:04 GMT -5 aquaduct said:

Ahhh, I see what happened here.......

nolanlawson.com/2022/06/09/the-collapse-of-complex-software/

I enjoyed that !

If ever we meet, I can bore you for hours on how uselessly complex today’s software is and for a reason. Driven by cheap hourly, outsourcing has taken over and the bean counters of the organizations that contract them just look at the hourly rate and call it a bargain. They never look at the fact that they; using the best documented techniques, build constant maintenance into their products and properly document the reasons for doing so. Simply put, it’s a mess.

On of the last contracts I had was with a major bank that I had worked for 3 times in a previous/pre merger capacity. This last time an ex boss sent me an email after hearing I was back again. I worked for him at the turn of the century. In the email he sent me a link to a page that had my calculation rate library on it. He said, we’re still using your code you wrote in 1999 ! I replied, couldn’t they come up with something better or are the just that lazy He said it works and has worked since you wrote, so no one bothers to look at it or wants to change it.

The effort to write it took 3 months. Today it probably would, with outsourcing, take 9 months for original design an initial implementation with constant maintenance, because “That’s how we do things here”

[theevan]

I know nothing about software, coding, etc, but I'm on the board of a barter exchange that contracted to write its own software. The initial program was sourced offshore. I'm not going to say it sucks thoroughly, but it sucks enough to require a redo. Our partners brought on an amazing programmer and gave him an ownership stake. What he has done by himself in a fraction of the time of the offshore crew is nothing short of amazing. It has been testing out flawlessly and positions the exchange for the long term. He makes BIG bucks in addition to his ownership stake. And he's WAY cheaper than the offshore bozos.

[gbacklin]

Jun 13, 2022 9:17:17 GMT -5 theevan said:

I know nothing about software, coding, etc, but I'm on the board of a barter exchange that contracted to write its own software. The initial program was sourced offshore. I'm not going to say it sucks thoroughly, but it sucks enough to require a redo. Our partners brought on an amazing programmer and gave him an ownership stake. What he has done by himself in a fraction of the time of the offshore crew is nothing short of amazing. It has been testing out flawlessly and positions the exchange for the long term. He makes BIG bucks in addition to his ownership stake. And he's WAY cheaper than the offshore bozos.

There are 3 major outsourcing companies and they are very, very big. Here is the way they do business as witnessed by me personally many, many times. How do I know what they did ? I was brought in to rewrite what they did I the story was always the same as yours.

This is what I had encountered in many industries. Government, Insurance, financial and retail.

The firm is bidding cheaper than anyone else. They wont compete against each other. Loyalty is the most important thing between the 3.

So they will start small with a few developers and a business liaison. The developers before the days of zoom, were chosen usually by a phone screen, where the person on the phone is not the person you get. Scheduling conflicts etc, however the phone screener is the specialist for the technology that is needed for the job. How do I know this ? I was contacted by an outsourcing company once to act as their phone screener... "because we have a hard time with the language, none of the developers speak English too well and that is losing jobs". I would have made $50 for every interview, where I would answer the technical questions and they would send in whoever was available, skilled or not. I told them to leave me alone.

Now back to the developers. If there are 3, one of them has a general idea how to work in the technology, the other two are on the job, being trained. They do not want to take the time to understand what is currently there, "because you are having issues, we can fix" or "That technology is not the best, we will make it better". So what they do is not touch the current codebase and then start adding their own. This is regardless of a new option to the application, or just a simple maintenance update. So now they start writing their code. The one who is the most knowledgeable on site, (but still has to contact the remote main office on how to do certain things, which they get from the guy who is doing all the interviewing) has to take the other two and tutor them. So that person gives one of them something to do and explains how to do it usually with links to stack overflow (a huge community Q&A pit, that usually gives really bad code examples) and the junior developers just copy and past the stack overflow example right into the code. Once I saw in the comment section of the code the developer just pasted the stack overflow link, because they had no idea what they were doing and didnt understand anything about what was needed, but the tutor pointed them to that link before he went on to the other junior developer. He does the same thing to the other junior developer.

Now after a few weeks, they now have more bugs than ever, so the business representative suggests to aid in this and to take this quality checking away from the hard working developers, so they can focus on developing, let's bring in about 3 QA (quality assurance) folks. This will improve the backlog we are experiencing. Well this cycle release itself and before you know it you have a QA staff of about 10, with a hierarchal structure "to make the QA process, streamlined" and now around 8 developers, "to increase feature turnaround".

Now after 6 months the recycling begins. Out of the 8 developers other than the original main person, you now have 4 who are up to speed with the code base and have increased their abilities 10 fold. So the company pulls those 4 off the project and replaces them with 4 junior developers and take the 4 and assigns them as the main person for other projects. All the while the company who hired them is paying a really cheap rate.

Now after about a year, the QA "Department" has grown to about 25 and the development staff to about 15. and the recycled developers have grown from 4 to 8, and they are so swamped with development and bug chasing (which they introduced to keep business coming in and justifies the additional staff) that they suggest a rewrite because of all the issues using outdated technology.

If you agree, then you are into "This is how we do things" approach. 3-4 months on discussing how to approach the new rewrite, 4-5 months on how to plan for all stages, request for training to get the skillset to their senior members, so they could be assured you will have the latest and greatest. Another 2-3 months upgrading all the software and tools needed for this revolutionary approach. 1-2 months assigning the staff and set schedules for the rewrite and then final comes the day to begin the rewrite. This then repeats the cycle that was used before.

They may generate code, but their main business is to generate ongoing business through bad practices that generates ongoing work forever.

But they are cheap/hour !!!


One company hired me to clean up and rewrite their mess. What took them 2 years to completely create the mess, I rewrote in 2.5 months. It was a 3 month contract, so after the 3 months were up, they thanked me. A year later they called me back in again to fix everything because after I left, they rehired that same contracting firm and they did the same thing again.

[aquaduct]

I've got plenty of experience with H1B's, too. They'll often work for a little as half as much as an American engineer in hopes of finding someone who will like their work enough to sponsor them for citizenship. The numerous screw ups are generally forgiven because employer can afford to do things twice.

But what caught my eye was my experience with PLCs in manufacturing. They're the ubiquitous machine controls that are everywhere these days. I originally started my career doing engine controls with Ford. That's the programming in the engine control module that makes your engine run (well, anything not carburated manufactured after the late 80's). Very simple programming scheme. Just a series of instructions from/to sensors and actuators that simply repeats over and over for the life of the vehicle.

After moving out here to basically a place that almost zero automotive control programming takes place, I sort of became fascinated with PLCs. They're exactly the same thing. Ladder logic, don't try to be too fancy because you've got to keep the cycle time under about 52 milliseconds before weird crap happens, do it right and it will run properly forever.

So at my last job the CEO came to us one day and asked for suggestions for improvement. I told my boss I'd love to try doing PLC programming and incorporating some of the diagnostic innovations that I'd learned at Ford (making the system a closed loop system so you could do stuff like predict motor failure before it actually shut the place down). At the time we'd lost our 3rd electrical engineer in 2 years and his old computer with all the software was available (a software license cost about $9000 annually and those folks could make a Abe Lincoln beg for mercy).

What was fascinating in relation to the article's point was that Allen Bradley had invented the PLC in 1970. We had one PLC1 unit on the floor that dated back to 1977- not used much but still chugging along. One day while chatting with an IT guy that had some experience with PLCs I asked if there were newer and fancier types of programming languages. He said no, ABI is selling the same stuff and any competitors are running a modified variation of the same thing so you have to buy their hardware in perpetuity. Better hardware, more memory, more I/O, but basically the same programming stuff. Why's that? "Still just as reliable as ever. Why change?"

I don't know for sure, but I'm betting the programming in autos is still pretty much the same game. Probably most of the reason why Tesla has so many issues (every single model they've ever made has been recalled)- they're running their controls like computers with all of that complexity built in.

Anyways, got to goof off with PLCs and do some nifty prove out of my theories until the guy that ran the manufacturing side hired an H1B electrical engineer from Mumbai that needed the computer. He lasted about 10 months.

[gbacklin]

Jun 13, 2022 11:35:26 GMT -5 aquaduct said:

I've got plenty of experience with H1B's, too. They'll often work for a little as half as much as an American engineer in hopes of finding someone who will like their work enough to sponsor them for citizenship. The numerous screw ups are generally forgiven because employer can afford to do things twice.

But what caught my eye was my experience with PLCs in manufacturing. They're the ubiquitous machine controls that are everywhere these days. I originally started my career doing engine controls with Ford. That's the programming in the engine control module that makes your engine run (well, anything not carburated manufactured after the late 80's). Very simple programming scheme. Just a series of instructions from/to sensors and actuators that simply repeats over and over for the life of the vehicle.

After moving out here to basically a place that almost zero automotive control programming takes place, I sort of became fascinated with PLCs. They're exactly the same thing. Ladder logic, don't try to be too fancy because you've got to keep the cycle time under about 52 milliseconds before weird crap happens, do it right and it will run properly forever.

So at my last job the CEO came to us one day and asked for suggestions for improvement. I told my boss I'd love to try doing PLC programming and incorporating some of the diagnostic innovations that I'd learned at Ford (making the system a closed loop system so you could do stuff like predict motor failure before it actually shut the place down). At the time we'd lost our 3rd electrical engineer in 2 years and his old computer with all the software was available (a software license cost about $9000 annually and those folks could make a Abe Lincoln beg for mercy).

What was fascinating in relation to the article's point was that Allen Bradley had invented the PLC in 1970. We had one PLC1 unit on the floor that dated back to 1977- not used much but still chugging along. One day while chatting with an IT guy that had some experience with PLCs I asked if there were newer and fancier types of programming languages. He said no, ABI is selling the same stuff and any competitors are running a modified variation of the same thing so you have to buy their hardware in perpetuity. Better hardware, more memory, more I/O, but basically the same programming stuff. Why's that? "Still just as reliable as ever. Why change?"

I don't know for sure, but I'm betting the programming in autos is still pretty much the same game. Probably most of the reason why Tesla has so many issues (every single model they've ever made has been recalled)- they're running their controls like computers with all of that complexity built in.

Anyways, got to goof off with PLCs and do some nifty prove out of my theories until the guy that ran the manufacturing side hired an H1B electrical engineer from Mumbai that needed the computer. He lasted about 10 months.

PLC's are very cool. I encountered them in my work I did for Inland Steel back in the 80's. I did not work directly with them as I was hired to write mixture algorithms for their sinter plant, but the guys that did, explained their role and skillset. Very bright guys and loved that not everyone wanted to be a PLC programmer

I also believe that when industry started phasing out PLC's for computer software solutions, the PLC's went to traffic light operation. I may be wrong on that, but that was what was told to me.

Another useless bit of info from me, was that in the late 80's-90's IBM had an operating system for PC's (OS/2). I did 9 years mostly direct for IBM for their customers in the financial and retail world. It beat Windows NT by a mile and was a really great os after they got it back from Microsoft, who hacked version 1.0 with funding from IBM, and unknown to IBM, use that money to develop Windows NT. IBM opened up its Boca Raton facility and totally dedicated a big effort to its rewrite. That was a very successful effort. Then they lost focus and came out with "Warp" versions and Unix (Linux) took the market by storm. Where did OS/2 go ? Into all the ATM's in the country. It was a very good multi tasking system (with scheduling mutex semaphores - for the geeky), but Unix was built from the ground up for networking, so it took over and remains today.

[aquaduct]

Jun 13, 2022 12:01:11 GMT -5 gbacklin said:

I also believe that when industry started phasing out PLC's for computer software solutions, the PLC's went to traffic light operation. I may be wrong on that, but that was what was told to me.

Yeah, I got the sense from my IT guy that there was some consideration of moving beyond PLCs at some point, but since this was only 3 years ago it ain't happening. Good old ABI (Rockwell) owns the market and PLCs are still everywhere you look.

[millring]

If you guys can't speak English I'm going to have to insist on having the moderators lock this thread.