Buggy code, fragile legacy systems, ill-conceived projects cost US businesses $2 trillion in 2020 Shoddy software cost the US an estimated $2.08tr in 2020, according to the Consortium for Information & Software Quality (CISQ). That's down slightly from a revised 2018 total of $2.1tr but still isn't anything to brag about. In its 2020 report, The Cost of Poor Software Quality in the US, the Massachusetts-based standards …
Yes.
Most of them were next to useless and couldn't code their way to a 'Hello World' app in a month of Sundays without referring to the internet first esp Stackoverflow.
|We blocked that site for a month and out so-called 'consultants' from India did virtually no coding. Not having the ability to cut and paste code (that often didn't work) really stymied them.
I'm sure that there are many other examples.
I had one "expert" come over who was meant to consult on deploying a new solution. All he did was cut and paste large swathes of vendor documentation (and I mean I was able to put in an entire paragraph and get an *exact* match, word for word).
Lets just say he didn't stick around too long....
Yes.
.Why is the situation so grim? The report argues there's an IT talent shortage, a claim others have made as well.
Perhaps rather than complaining about artificial skill shortage it might be time to take a really good look at methodologies as well and reassess whether trying to shoehorn agile into every single project was such a great idea. Who knows, it might not be the best approach to every single application/project.
Too many people trying to push over aggresive changes in too shart a time.
When working on large projects any changes have to be carefully thought out. Agile is not so usefull when you are working on a mature system. You cannot just plug in half a screen or table and hope it will work.
China Joe Biden will bow down the tech companies that helped him steal the election.
He'll open up the H1B flood gates bringing in hoards of incompetents and also demand to retrain the unemployed baristas to become 10 week wonders.
The truth is that we need good software engineers. But it takes 4-5 years of training.
As part of our interview process we have a test that involves some fairly simple coding questions that must be answered without looking anything up. You would not believe the number of applicants who either walk out (these are what I'd call scammers) or fail miserably (these I'd call lacking in any noticable skill). And the quality of applicants applying to jobs doesn't increase for senior positions, often the applicants for senior positions are worse than the junior applicants.
Just been let go by a US bank. They have lost all respect for any IT skills/aptitude and have the attitude that anyone can code, as long as it's all API based or whatever weed enhanced fad has been dreamt up in California this week to sell more books. All passwords being replaced with trusted authentication for example. Even where its blindingly obvious that it leaves all your data sources open for abuse.
It is blindingly obvious that the US bank you just left is ripe for a Post-COBOL Apocalypse event. The kind that happens when obvious and relatively easy to understand COBOL code is abandoned for "sexier" languages, known to coders as, "Job Security". [Posting anonymously because, among other negative traits, brogrammers don't take criticism well.]
Although I agree that a lot of people could be retrained to code, 'retraining' in most politician's minds, is to put a coal-miner in front of a computer and tell him 'to work smarter, not harder'.
In their mind, 'IT is easy', they're using their smart phone without much of an issue, how much harder could it be to write code?!
The reason why so much money is wasted in IT is due the 'Dunning-Kruger' is strong in a lot of managers.
This is why HP flourished when the original founders were still involved and the finest quaity product they put out today is printer ink.
As friend put it, "Computer programming is the most difficult branch of applied mathematics."
No. Most people really cannot be trained up to that level. In fact, most people currently employed as programmers cannot. What they can do is produce a lot of code that mostly works in the two or three cases that they thought about. When the bug reports come back, they make the entire thing more complex (introducing new bugs) trying to close it.
Getting this stuff right is HARD. Just like most people cannot be "trained up" to be civil engineers or aerospace engineers, they cannot be trained up to be software engineers. And that is where the shortage lies.
No. Most people really cannot be trained up to that level. In fact, most people currently employed as programmers cannot. What they can do is produce a lot of code that mostly works
Completely agree. Hence my use of the term 'coders'. There's a huge difference between being able to code and doing software engineering
Just the representation of 'hackers' in popular media shows the infantile perception that most people have of IT. That lack of knowledge is the main reason in of the wasted $2 trillion/yr.
Combined with managers who can't think much further ahead than the next financial quarter and it's no wonder IT is in the state it's in.
totally agree
in a software firm you need a core group of Programmers or software engineers to create the program logic and flow a build in the security etc., then you need a miriad of coders to translate this logic into the miriad of languages used across the miriad of platforms.
Manglement in their effort to cut costs said why are we paying the core group so much, why not just pay them the same, so quality did as it does and left the sinking ships, this is why we see less and less inovative features, and more tweaks to current code, building up more and more technical debt....
If you pay me enough I'm willing to learn any language that exists, COBOL isn't even particularly complicated it's just very very unproductive. I'd argue that any truly proficient developer would be able to pick up nearly any language fairly quickly with the right level of motivation.
While the article qualifies the usual assertion of a developer shortage by noting a shortage of good developers, I simply cannot see the difficulty.
We all know the definition of a good developer, it's someone who delivers on time and on budget. Accomplishing this goal merely requires a calendar and a calculator, both of which are included with Microsoft Windows and all the other (admittedly minor) players in the desktop and server space.
The CASE tool renaissance of the late 1980s taught us that the act of writing code is so trivial a task that it can be automated. The Y2K crisis taught us that anyone can engage in the act of writing code having augmented their keyboarding skills with a "Learn language in n [hours|days|weeks]" book.
Disabusing decision makers of the above load of equine excrement is going to be difficult. In the middle of the last decade of the previous century I recited to my boss that old saw about "cheap, fast, or efficient - pick any two." He replied that he'd heard that one, and he wanted all three. I took another offer soon after. And no lesson was learned.
The mindset that software developers are resources to not just be used, but used up is pervasive. That software development and project management are othogonal remains unknown to those who design org charts and compensation plans.
This is not a problem that gets fixed by adding more developers, no matter how good they are.
The core new clear problem to see is always the same and is something which cannot be fixed, but that doesn't stop deaf, dumb and blind and intellectually challenged systems administrations from tasking future developers and systems administrations with the same impossible and increasingly rapidly eventually inescapable and personally identifying self-destructive task ...... the ever more complicated defence of the indefensible that constantly inspires and feeds ever more stealthy and increasingly damaging and deadly attacks.
The simplest of complex solutions is easy to see and share ....... Stop trying to fix something impossible to fix and just simply decline to continue to defend the indefensible and inequitable and iniquitous.
IT aint FCUKing Rocket Science ...... Greater Common Sense.
What this needs is an acronym.
From the article: the report calls for better software defect detection and remediation of identified vulnerabilities
B.S.D.D.n.R.O.I.V (ok maybe not)
But I usually solve these *kinds* of problems through Super High Intensity Testing.
And that's an acronym that's easy to remember!
the answer is not detecting the defects and fixing them
the answer is not making the defects in the first place.
this is why you need programmers and engineers, not coders.
Heres an acronym for the Authour of the piece:
Forget Usual Coding Knowledge Or Finding Faults, Treat With Adept Talent
I do not consider myself a developer, nor a coder, but a programmer. I will use a library if I know what it does inside, outside, topside...every side in every conceivable case I can muster. I will test it thoroughly as I test my own code. I am costly in both time and money, but strive to produce as correct code as I can; aka quality.
Many, many years ago, I was contacted to produce a payroll system for a company which had expanded from a single tax jurisdiction to multiple. They wanted the thing done in a month, they could not wait. I replied I would require no less than three months with one or two contingency until I could analyse the requirements. I did not get the job. Fast forward five years and I found out the "coder" the hire instead of me had delivered in two months instead of the agreed one. And, they were still working out bugs and had dozens of work arounds to process payroll including pre- and post- processing with a spreadsheet. They are now out of business.
The problem is unwillingness to pay for suitable quality. This goes far beyond software in IT. IT security is afflicted. It also does not help that the current trend of software is change for change sake and the abominations we are seeing is horrendous. There are losses due to abandonment of well reasoned user interface elements. How much time(money) is wasted when a form rejects input on submit when the input is formatted had been formatted in common form and only instructing the user of the expected form after the fact? Not really a rhetorical question, I just do not have the resources to make that determination. I can write a routine to transform input in common forms to the desired form for processing, I do not consider it to be time consuming or challenging. There are so many examples of poor programming, I could write an encyclopedia on the topic.
I agree training more developers is not the fix. The problem is deeper and requires a more complicated mitigation and is not likely to be accepted by those who make the decisions.
Referring to notes on Sainsbury's online shopping account, (1) the password must have big and little letters, numbers, and NO spaces, (2) I didn't know that when I went about setting it up, and (3) I've never yet used it.
Another service apparently doesn't work with a Yahoo e-mail account - I mean, yes, I know, but why shouldn't I. Nowhere does it say, while creating an account, that it won't work. This includes the account user authentication e-mail. Result, no usable account and a big waste of time.
Despite the shortage of developers, agencies will reject those of a certain age. Past that age, stay where you are (if you can) because get a new role will be tough. Of course, rejection for reasons of age is illegal so it's because "the company wants people to be there long term".
The mystery is why an industry filled with educated people decided to outsource hiring to the recruitment industry, an industry filled with people that are smart in a different way.
The mystery is why an industry filled with educated people decided to outsource hiring to the recruitment industry
They’re the same reasons why a cohort filled with educated people decided to outsource finding a mate to the matchmaking industry — viz the convenience of someone else doing the drudgery of weeding out clearly unsuitable potential partners, and the belief that a specialist in making matches can find an ideal partner for someone more readily than that selfsame someone could.
The clients of the recruitment industry want their developers “just so” — possessing every technical and personal skill that is needed for a position so that they can “hit the ground running“ on the first day of work. However, those clients are generally not willing to either (1) offer enough to tempt fully qualified but happily employed developers away from their current positions, or (2) invest enough into mostly qualified but frustratingly unemployed developers to bring them up to speed to the clients’ particular skill requirements. As a result, that industry filled with educated people is perpetually bemoaning the lack of availability of suitable developers — which does nothing to help unemployed developers, be they in chromotrichopause or no. Until that industry realizes that in one way or another they’ll need to use more from those hoards of venture capital to get the employees that they want, the situation won’t change, much to everyone’s detriment.
As an aged migrant to IT with non IT stem degrees (early 50's when I moved) I landed a couple of jobs. One was to gain experience (pay sucked but the experience was needed). The next job has much better pay and long term stability (switched industries). The real issue is not there are not skilled programmers available or people with enough general technical skills to transition to IT, it is many elements think if you over 30/35 you are washed up and untrainable. But what they throw away is experience and the wisdom experience teaches.
I haven't had that problem at all --- I'm in my late fifties and get a steady stream of contacts from recruiters.
Or maybe the "certain age" you're thinking of is somewhat older than mine?
Around here there seems to be plenty of demand for experienced developers.
"Of course, rejection for reasons of age is illegal so it's because "the company wants people to be there long term"."
The interesting thing is that most younger workers are going to job hop. Older workers aren't as interested in moving house every six months and may have family nearby they don't want to move away from.
Companies have created this monster themselves. For many people, the only way to get a raise or move up the ladder is to change jobs. That will be their first move if they see the company bringing in outside people over them rather than promoting from within.
You cannot write decent code if you do not understand the context. As in, the business, the workflow, what the code should actually do.
How many coders (or anyone involved with coding) ever have that type of knowledge?
Bugger all is the answer. So, this naturally leads to the result that all you get is an “Agile” serving of bad spaghetti.
Yes. But that treats coding as a tool rather than as a specialized profession. I've come away from a few organizations that hid all their software devs in a separate department. (With its own highly paid management structure.) And insisted that anything involving 'code' could not be touched by their rank and file engineers.
Code is more like a tool. I expect any competent mechanic to be able to handle wrenches, screwdrivers (and most importantly) large hammers. I expect that their knowledge extends to diesel engines, washing machines or clocks. And they know when to select the proper tool as needed. I'd hesitate to hire a mechanic whose field of expertise was 'pipe wrench'. But that's what we do for software.
Sure, there's tons of code out there that "works" today and will be upgraded next week ... maybe - don't worry if the upgrade has a bug because we can update it later. Hardware is built the same way too, phones work great and then the battery dies and you need to buy a new phone. We're told that keyless cars are more secure and easier to use, but they get hacked or just driven off because the driver left the key fob in the car at the gas station. Nobody buys CD and records anymore because it's easier to stream music ... this is killing new bands and artist but it's making the streaming companies rich, the phone companies are building new phones all the time ... everyone's making money from unreliable products.
Look at the Irish backstop and the great Brexit agreement that achieved everything ... written the same way that applications are written - achieving a solution today that will need an update... this is normal isn't it?
Yes of course. The Brexit agreement has been developed in an Agile Fashion. Now of course it will require endless additional releases, without any time spent on the technical debt that will be introduced as we go. So yes it is normal...
Knowing how to implement something isn't the same as knowing how to design it. The two skills might look the same to the untutored eye but just as knowing how to throw a plank over a ditch doesn't make you a bridge builder knowing how to code doesn't make you a programmer. Coding is an implementation skill, its an essential skill, just like being able to read and write, but just as being able to write doesn't automatically make you a great author being able to code doesn't make you a programmer..
It doesn't help that a lot of coding is done inside frameworks that hide most detail from the coder. This is great from a cost-savings/productivity perspective but it has serious limitations should the requirements of the job fall outside the capabilites of the framework. Here experienced programmers will know just where the edge is -- how far you can go inside the framework before things fall apart -- and either adjust the design to fit inside the framework or build a new structure that accomodates the requirements of the task.
One of the major details were I work isn't the coding, often it is pretty straightforward but properly interpreting the requirements and knowing when to get clarification of the requirements. It's the translation of the requirements to working code that is the real skill. A skill which is broadly language independent (obviously you need to know the desired site language).
It's not just IT. It's not just corporations. It's society.
Consumers, in general, are unwilling to pay more or wait longer for a quality product.
Take burgers. It is easy to find a better burger than McDonald's serves but it costs more and takes longer to prepare. Hence most people opt for McDonald's or other fast-food chain.
Or take Cyberpunk 2077. The company had to meet a holiday release deadline or they would lose sales and they couldn't raise the price because, again, they would lose sales.
How many of us would pay extra for a formerly free and open source product if it meant that the developer would be paid full-time and could hire additional full-time developers.
How many of us would pay extra for a formerly free and open source product if it meant that the developer would be paid full-time and could hire additional full-time developers.
Sure, absolutely, but only if I kept getting the source code under the same terms, i.e. being able to modify and enhance without paying some kind of subscription fee in perpetuity even if the developer(s) stopped developing.
It's Leo all over again.
When Leo came out, they'd develop a business system by understanding how it worked and make a bespoke system.
Naturally businesses caught onto this and started to develop systems that were bog standard and quoted low prices that caused the client to accept software that wasn't made for them and their business suffered.
History is doomed to repeat itself if you're ignoring it....
The icon is appropriate.
Many many years ago, I wrote code. A specification was written for us by somebody who sort of understood the problem, but nothing about the application of that to a computer. That was supposed to be our job, to take the spec and make it code.
Only, it wasn't. Our job, it transpires, was to take the spec extremely literally and make it code. An example I remember was a set of values that were multiplied by powers of two. I forget the reason, index offset maybe? But it was basically a calculation that the sixteen bit processor could do as a simple arithmetic shift. But no. The spec said that the value had to be multiplied, so a costly multiplication routine needed to be invoked. But we couldn't write one because we already had an even costlier multiplication routine that worked with fixed point numbers. So, yes, we took a value and converted it to fixed point and multiplied it and converted it back. Hundreds of machine cycles for something that ought to have been one instruction.
Why? Because the spec said so and some asshole manager wasn't going to accept any deviation from the spec. NONE.
The project was full of stuff like that, and arguments between the programmers (I was just a junior keyboard monkey) and the manglement were common. And since the higher ups understood their sycophants and not us, we were overruled every single time. I left before the project was anywhere near finished (and already late) and it was an utter piece of shit. Bloated, slow, horrific. Nobody wanted to put their name to it. But, alas, it completely followed the spec. The spec written by somebody barely competent to use a pocket calculator.
Suffice to say, I took a completely different career path. Pays less than a developer, sure, but less stress and I got to meet some interesting people. Best discussion I ever had with somebody was working as a carer in a nursing home with this excited old lady jumping up and down about as much as possible in a wheelchair. Why? Official secrets was up, she helped bust the Enigma and had been waiting a lifetime to talk about it. And she did. Utterly fascinating how it worked and the methods used to reverse engineer something just by looking at the encoded messages.
I don't regret my decision, but I do regret that once upon a time people were valued for their skills. Writing code, running an effective ward (in a hospital), being a blacksmith... and somewhere along the line we all accepted these total and utter losers to come along, call themselves fancy titles, tell us all what to do. They don't have a bloody clue. I bet you could randomly fire at least half the management from any company and when the shock settles down, you'd realise that they weren't actually that necessary and maybe just maybe the workers would be more effective by not having people that don't understand their job telling them how to do their job, and of course (especially in high concentration jobs like programming) not having to stop everything mid morning for yet another stupid fucking "update" meeting where everybody is brought together to say where they are different to yesterday, or the day before that. It doesn't help the programmers, it doesn't help the other workers, it's only done in order to make the management feel like they are important.
They are the reason we're all screwed. People worship the guy with the big desk and the company car.
And the people that can actually do the work? Diminishing, mostly due to the actions of the aforementioned parasites.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
