14 Comments

This is one of the stupidest commentaries I have ever seen.

It makes horrible assumptions, including that AI is smart enough to replace a software engineer. I tried, it cannot. It can assist in a great many ways, but thats it.

Expand full comment

More than once you state that human programmers, on purpose make their code difficult to read and maintain. I have never seen that happen on purpose. Usually these things come about because the business changes its mind or never knew what they really wanted and the constant waffling back and forth causes technical debt.

I don't see this changing just because AI is now the programmer.

Expand full comment

I admit that blaming human programmers is too antagonistic and flame stoking on my part (although not as far from the truth that many programmers will be willing to admit even to themselves).

However, the lack of time for optimising/simplifying the system for the latest whim of the product/project management has essentially the same effect, technical debt. Technical debt also can manifest externally as unreliabity and inefficiency of the product.

AI software development will be so much cheaper than human (unless human role is reduced to rubber-stamping AI's work completely mindlessly) that AI *will* have resources for refactoring whenever needed, keeping the system with rather minimal accidental complexity and tech debt.

Then product/system management may still be poor, mandate too many features, for example. That's why I also noted that system complexity governance (by the org leadership, and even external) will b important. But just the quality of product management will be important, too.

But yes, I agree that people who currently play the roles of engineers would often make better software product managers than an average product manager today.

Expand full comment

Furthermore AI is far from being a programmer. Author should just try to replace a junior level programmer with AI, he'll changes his mind.

Expand full comment

Very funny. There must be a plot by software developers to bring down the world, perhaps they eat children too.

Expand full comment

Whatamaroon...

Expand full comment

AI really only copies code created by human programmers, if as you state that source is so overly complicated, its seems naive to suggest that the use of AI will produce simplified or optimized code.

In fact its difficult to show correctness of software, much less optimal simplifies software. AI is not a magic bullet.

Expand full comment

have been undercover in the software industry for 30 years (they started calling me an "engineer" so now I am undercover pretending to pretend).

I have PROOF that software kills puppies!!

I agree with this "author" that we should "shred [sic] human software engineers as quickly as possible".

Yes... shred them! Puppies will thank you.

Expand full comment

nah… just… nah…

Expand full comment

lol. how old are you?

What's the point of you writing this article? AI can just write 99% of the articles in the world. Well, except the 1% in certain government-regulated industries, that is

Expand full comment

Replace Human Intelligence with Artificial Intuition. That makes so much sense!!! As we all know intuition can always be trusted.

Expand full comment

This article must have been written by AI.

"Alas, bloated, inefficient, unreliable, wicked software will be written by human software engineers to increase their job security. The side effect of this is that the software brings less value to its users and other stakeholders."

Everywhere I've worked, someone writing wicked and unreliable code as described in this article would be fired.

Expand full comment

Its not the software developers and engineers we need to eliminate but the terrible technical management they often work under.

Software developers are driven by a few specific criteria when they work; technology interests, decent salaries, and some semblance of a work-life balance (who wants to be on call 24/7?).

Despite these features the majority of software professionals labor under terrible stresses that are often fostered not only by bad technical management but vendor agendas that are often unrealistic and subsequently introduce increasing complexity to the software professional's job.

I go back to the classic example, which I have been writing and commenting on for years... The move from Microsoft's ASP.NET WebForms to ASP.NET MVC and now the ASP.NET Core\Blazor paradigm turned web development on its head. This change was fostered not only by Microsoft but industry "carnival barkers" and so-called software-purists, the latter of which probably never worked under pressures of deadlines. Had they done so they would have refuted such a technology move as well.

The needs of software developers are basically quite simplistic from a professional view; quality tools that provide the least complexity to enable them to reach reasonable deadlines. Anything else is a waste of time and subsequently monies, which are often increased under such vendor pressures.

Was ASP.NET WebForms perfect? Absolutely not! Nonetheless, it made web development rather straight-forward while allowing Microsoft to promote similar form of desktop development with its XAML-based WPF environment.

What do we have now? A mess inside the web development community using Microsoft tools, which have always been unnecessary.

Microsoft then moved a lot of development to its new .NET Core environments, which has done little to make web development any easier. In fact, Microsoft threw out a number of environments that it didn't want to be bothered converting to the new Core Frameworks such as WCF, which quite a few companies have invested heavily in considering that it provides for proper support for distributed systems development.

Microsoft SilverLight, an excellent framework for developing web applications, was thrown to the side years earlier. Luckily, for the development community, the OpenSilver Group has now provided an increasingly excellent replacement while the CoreWCF Group has made up for the elimination of the earlier WCF environment.

lot of this was completely unnecessary and is a major reason why one doesn't see the same issues with the Java Development Environments. Those environments are still chugging long with basically the same paradigms they have been using for years while refining the internals.

Of course we can find blame for the poorer quality software developer that appears to be a growing issue in the industry. However, that is not a reason to trash the entire software population.

If more of these so-called engineers who write articles such as this would spend more time demonstrating the need for quality tools and paradigms instead of the rampant bullshit that has been fostered on our profession since 2010, things could have been a lot different.

But here we are...

Expand full comment

Blog post is cheap. Show me code.

Expand full comment