* Posts by Jeff Jones

8 publicly visible posts • joined 2 Mar 2020

Microsoft partners beware: Action Pack to be retired in 2025

Jeff Jones

More market speak...

"... evolving the partner benefits offerings to provide partners with the tools and support they need to continue to lead the way in the shifting tech landscape."

Let me translate this to normal (American) English:

"We are altering the partner benefits deal to save us money. Pray I alter it no further."

Hey Microsoft – what ever happened to 'Developers, developers, developers'?

Jeff Jones

MS is getting more and more dev-unfriendly

The separation from dev (paying customers) by MS's development tools part of the organization has been going on a while.

MS abandoned Rapid Application Development (RAD), in which MS was dominant in the 1990s and into the 2000s, when the script-kiddies that rose to management positions decided that drag-and-drop UI designers (like the WinForms one that works so well, and was inherited in Visual Studio from Visual Basic) were unnecessary (Xamarin/MAUI, Blazor, WinUI3). The significant increase in development time as compared to the use of a RAD designer led to companies having to spend more on initial UI development time plus the inherent increase in layout errors and bugs from hand-coding the UI. The use of "Hot Reload" as a substitute is a joke. It does nothing to remove the time spent hand-coding the UI.

It is ironic that MS's Visual Studio that set the standard for visual UI development no longer has the "visual" aspect in UI development.

Alan Cooper and his small team did not take long to develop the first WinForms visual designer. Apparently, MS no longer has that caliber of developers to produce an up-to-date RAD UI Designer. It is not like they do not have the money. A team of the right people (a "Skunkworks" type team), 10 to 12 in number, could have a single RAD UI designer extension done within a year that services WinForms, WinUI3, MAUI, and Blazor. How MS does not see the payback in market share from providing this RAD tool, like they saw it in the late 1990s, is beyond me. It seems like they are looking at finding excuses not to build one to whine about, instead of real leadership that figures out how to get it done, and then does it with excellence.

There are several other areas within how Visual Studio works that show MS not being concerned with developers.

Google: We're still working to defeat Microsoft's 'anticompetitive' cloud policy

Jeff Jones

Jealousy

Amazon Web Services (AWS) is objecting simply because Azure has taken so much of the market share AWS once controlled by Azure offering a better cloud product.

AWS is just playing the regulatory game (given that the EU is much more anti-capitalist than the US) to nip at the heels of Azure to make it more costly for Azure to do business in Europe.

It is not about competition - it is about Google wanting to dominate the cloud industry and keep dominating it.

I’d rather see less regulation and less government preferences in law, and more real competition by all cloud providers having to offer better products and services to gain market share. Government should not be used to affect that very capitalist approach to competition, rather than the corporatist approach we see now.

Innovation that produces value greater than cost comes only from a free market, capitalist approach, not from corporatism.

Mamas, don't let your babies grow up to be coders, Jensen Huang warns

Jeff Jones

Fact or Fiction?

AI/ML is in no danger of replacing software engineers. At best, it is capable of generating simple code, not design and the code to go with it that is efficient, scalable, supportable, etc. I use AI/ML for simple, repetitive tasks in my coding, usually having to correct the generated code, or ignore it altogether as being worthless. I started writing AI/ML with MS's ML.NET years ago, and see a lot of good uses of AI/ML, as long as the software engineer sticks to reality and not science fiction and fantasy.

AI/ML is not capable of thinking or reasoning alone. AI/ML can only do what it has been trained to do, which depend on humans with very large training data, which makes the AI/ML generative output limited to how good the training data is (which depends on how knowledgeable the humans that made the training data).

I see the future of people working in software engineering to be one where coders, hackers, "script kiddies", etc. will be largely (but not totally) eft out or replaced, but those who approach software engineering holistically with engineering and business acumen, and understanding users, able to think creatively and with deductive reasoning, to do well and have long careers.

AI/ML is a good tool (of many tools) for such software engineers but can never replace them. AI/ML replacing software engineers is pure science fiction.

Jeff Jones

Re: A little test

"we propose letting an AI run the Nuclear power plant near you (What could go wrong)"

I operated nuclear power plants (as a licensed, trained operator) from the age of 19 to 21. I wouldn't let AI/ML anywhere near the operation of the plant, whether reactor or auxiliaries.

Microsoft hiring a nuclear power program manager, because AI needs lots of 'leccy

Jeff Jones

Go with a Navy Nuc

When I was 19 years old, I (and many of my fellow Navy Nucs) were certified to operate nuclear power plants, steeped in intense, “sink or swim” academic training followed by “hands on” training at real, operating, nuclear power plants. Navy Nucs are an elite and highly capable group of people and there are no ex-Navy Nucs.

If Microsoft wants the best success out of this effort, the person they should hire is a former Navy Nuc, who made it to the fleet (meaning operating a shipboard nuclear power plant), who also has deep experience in software engineering and product management after leaving the Navy.

Navy Nucs are trained how to learn anything quickly and with proficiency. They understand the science, engineering, operations, maintenance, and ever-changing regulations related to nuclear power. Navy Nucs know how to relate to the non-technical and technical stakeholders.

Of the thousands of experienced, former Navy Nucs, there are at least hundreds from which to choose.

From browser brat to backend boss: Will WASM win the web wars?

Jeff Jones

Some missing facts

First of all, before Java, Visual Basic was ported to UNIX, later Linux, and other minicomputer OSs by a licensed third party, which achieved “write once, run anywhere”. Because there was no IDE that ran natively on those OSs, it never caught on.

Second, Microsoft Blazor has pioneered the use of WASM and still does. C# in the browser and the backend has been around a few years, and works beautifully. .NET, starting with .NET 5, and open-source C#, in a short time delivered “write once, run anywhere”.

If you want to take advantage of WASM today, the best implementation is found in Blazor with C#. As far as WASM on the server, why? We have C# and Java for that, which already have great performance and broad access to everything from IoT to massively parallel servers.

I am at a loss as to why this article, otherwise quite good, has no mention of the positive and pioneering work Microsoft has done in bringing WASM into the mainstream.

'Developers have lost hope Microsoft will do the right thing'... Redmond urged to make WinUI cross-platform

Jeff Jones

A couple of observations

1. What gave Microsoft the commanding lead in development at one time was the quality and power of the UI designer. Even in Visual Basic 1 days, the UI designer was the core of the rapid application development (RAD) IDE, and copied by competitors. As WinForms shifts to .NET Core, and UI development in XAML (Xamarin, UWP) and HTML (Blazor) become dominant in MS development, the RAD UI designers are lacking. That takes a large part away from Visual Studio being a RAD tool when it comes to UI. MS needs to invest in some seasoned software developers at the same level of competence as the ones who originally made, and updated, the VB/VS WinForms UI designer. The current crop of MS developers apparently cannot cut it.

2. Back in the 80s and 90s, Mainsoft (and another company I cannot recall) ported the Win16 and Win32 APIs to UNIX, then Linux, and other OSs. The other company ported the VB runtime to those same platforms using Mainsoft's work. You could, literally, use the VB IDE on windows to write VB applications, then compile and run them on the other OSs. If they could do that back then, why cannot MS port WinForms to run on multiple OSs today?

A common thread here is that the quality, creativity, and production of MS developers 30 years ago is ahead of the what MS is hiring today.