A first attempt at AI was ... educational

I decided to try AI.

I devised a simple task: create a spreadsheet to calculate loan payments. Specifically for an auto loan.

For the AI engine, I selected Google's Gemini. This was a random choice; I had no reason to favor Gemini over other AI engines.

My prompt to Gemini was something along the lines of "create a spreadsheet to calculate payments for a car loan". I don't remember the exact prompt.

I had expected Gemini to create a spreadsheet that let me enter the cost of the car, a down payment, an interest rate, and a term. Google did create a spreadsheet (after I went to various setting pages and enabled "smart features") but the spreadsheet ... didn't work.

The spreadsheet was kind of correct but mostly wrong. There were two types of errors, both related to formulas. The first was an error in column references: the formulas referred to column A, when the values to which they referred were in column B.

The second error was one that occurred when transferring the AI results into the spreadsheet. One formula used the 'PMT' function with three arguments. The three arguments were split into three different cells. The splits occurred where there are normally commas. So the proper formula 'PMT(A4/12,A5,-A6)' became the three cells 'PMT(A4/12', 'A5, and '-A6)'. Notice that the splits are exactly where the commas should be. (The negative sign in the last argument is correct; that's the way the PMT function works.)

Upon seeing the spreadsheet (and its errors), my first thought was "If this is the quality of Gemini, Google is in big trouble.".

My second thought was "Maybe I should write another prompt, asking Gemini to fix the spreadsheet.". I expect many people would do that. I chose not to. I was disappointed in Gemini's output: these two problems are significant. How could Gemini make these errors?

If AI needs additional prompts to get things right, even for a trivial task, what do we do for larger and more complex tasks? I can re-prompt Gemini to get it to fix errors, but only if I know that there are errors. 

I don't see how AI can help if it generates the wrong result and needs additional prompting to make things work. And I'm not sure that I will be able to identify errors or problems when the thing created by AI is large and complex. Asking AI to check its work requires that we trust AI, which we cannot. Even asking a different AI engine isn't a solution; how can we trust that engine?

My impression of AI is that it can do some interesting things but we cannot trust the results. If we cannot trust the results then I'm not sure that AI helps -- in any effort. At least for now.

Microsoft forces AI on developers

Microsoft, in a recent update to its Visual Studio IDE, has forced Copilot AI onto developers. It's not an obvious change, in fact, it affects a rarely-used corner of the IDE: the profiler.

A profiler is a useful if not often used tool. Most of the time a programmer is editing the code. Somewhat less time is spent compiling and linking the source code into executable files. Depending on the developer and the quality of the code (which may have been written by others) some amount of time is spent debugging the code - running the code in 'slow motion' and observing which lines are executed and which are not.

The profiler is a tool to measure the code, specifically as it runs. Different profilers (or different parts of a large profiler) measure the time to execute functions (to identify which functions are slow), the amount of memory used, file operations, and "code coverage" (to identify code that is not tested).

Microsoft's Visual Studio has a profiler built as one of its tools. (And it's a nice, capable profiler.)

But Microsoft's latest version of Visual Studio adds Copilot to the profiler, and adds it in such a way that you cannot use the profiler without using Copilot. (You don't seem to have to pay for this specific use of Copilot, though.)

It so happens that a client has decided to disable Copilot in their organization. (Exactly how is not important.) They have their reasons to do so, and while I may not agree with their reasons I do agree with their goal of disabling Copilot. (I think Copilot and the other programming AIs are not quite ready for prime time.)

Working in this environment it is obvious that the new version of Visual Studio is dependent on Copilot: the profiler refuses to run. (It's not quite obvious; it took a few seasoned hands to identify the connection.)

A few observations about this change:

First, Microsoft, rather than allowing developers to enable Copilot, is forcing Copilot upon them. That's not going to win them many friends. Selling a new feature ("See this new feature! It's shiny!") tends to keep people on your team. Forcing a change makes people angry -- possibly angry enough to leave your team.

Second, Microsoft has built a new profiler that requires Copilot and cannot work without it. This is a poor design choice. Good design of systems allows components to work even when parts of them are not available. (And as the profiler worked just fine without Copilot two weeks ago, I don't see how Copilot is such a necessary part of the profiler.)

Third, if Microsoft is willing to force Copilot onto developers for the profiling tool, they may be planning to force Copilot onto developers for other parts of Visual Studio. Auto-completion, for example. Or syntax coloring. Or debugging. Or maybe even code optimization by the compiler. I'm not sure Copilot is ready for such tasks.

Fourth, if Microsoft is willing to force Copilot onto developers, they may be planning to force Copilot onto other users -- in Microsoft tools such a as Word, Excel, Powerpoint, Access, and maybe even things like Maps. (I'm not talking about making Copilot available to these tools; I'm suggesting that Microsoft make Copilot mandatory in these tools.)

The bundling of Copilot into the Visual Studio profiler is a small change for a small audience. I don't see people in significant numbers moving away from Microsoft because of it. A few might, but nothing significant.

But it doesn't increase the appeal of Visual Studio. Developers like control over their tools. I don't see people joining Microsoft's team because they are forced to use Copilot.

One could interpret this change (for Visual Studio) as an experiment: Will users work with Copilot? Or as an act of desperation: We need to get higher usage numbers for Copilot. In either case, it's an internal issue. Microsoft is not boosting its appeal to developers, and not setting a higher standard for its competitors to meet. As an internal issue, the rating of success (or failure) will be determined by internal numbers. I don't expect we'll see more about this change.

UPDATE: A later version of Visual Studio removes the hard dependency on Copilot. I don't know that it removes Copilot completely, or if it simply allows the Visual Studio profiler to run with or without Copilot (using AI if available, not using AI if not available). I haven't seen complaints on the internet, so I imagine that Microsoft made this change on their own. It may be that the forced use of Copilot was a mistake and Microsoft never had plans to force users to adopt Copilot (for the profiler).

Closing the "Iron Triangle"

Microsoft's new releases of Outlook and Media Player highlight a coming crisis for software development. There are two problems, caused by the closing the "Iron Triangle" of software development.

The Iron Triangle is a phrase to succinctly state that software development requires trade-offs among  three aspects: cost, quality, and performance. It is easy to build software that is cheap -- as long as it doesn't have to work right and doesn't have to be fast. It is easy to build software that is correct -- as long as it doesn't have to be fast and the budget is high enough. It is easy to build software cheaply -- as long as you don't care about quality or performance. It is easy to meet one of the three aspects.

It's somewhat harder (but still easy) to work within two aspects (say, cost and quality) while not caring about the third (performance, in this case).

Working with constraints for all three aspects (cost, quality, and performance) is difficult. Extremely difficult. More on this later.

Back to Microsoft and its new versions of Outlook and Media Player.

The first problem is that both the new Outlook and the new Media Player are slower and use more memory than the previous versions. (The new Media Player also wants payment for some previously free codecs, but that is a separate issue.)

I told a fib there. The problem is not that new Outlook and new Media Player have lower performance. The problem is that people have noticed. People are now aware of changes to performance, probably because they have  already planned to delay hardware upgrades. (Possibly due to higher prices or lack of availability. Possibly because they are reluctant to upgrade after recent upgrades for Windows 11's higher requirements for hardware.)

The second, and larger, problem is that Microsoft has long relied on Moore's Law. (Moore's Law states that the size of a transistor halves every eighteen months. It can roughly be read as "computing power for CPU and memory doubles every two years".) Microsoft is not alone in this.

Relying on Moore's Law means that development shops can design and build software that is large and slow. Instead of designing lightweight, efficient software, shops can build heavy software with poor performance, and then wait two years. The next generation of computers will be faster and the performance will be acceptable (on the new, faster hardware).

It's a nice arrangement, and it works... until it doesn't.

The rate of reduction of transistor sizes has slowed. Over time we learn to build smaller transistors, but not at the rate of "half the size every eighteen months". Effectively, the time to double performance has increased, which means that users cannot simply wait two years for better performance.

If the size of transistors is not enough, the demand for hardware to build AI data centers has affected the cost and availability of PCs. Costs of "regular" PCs are up. Availability of memory and disk drives (either SSD or HDD) are down, and their costs are up. It's not just that new PCs are not as "faster" as they used to be, it's that PCs are more expensive and only slightly faster than they used to be. Consequently, PCs aren't replaced or upgraded as often as they used to be.

All of this means that the hardware used by customers is stagnant. It's not improving in terms of performance.

If the providers of software, either PC apps or web apps (because web apps run on PC browsers), want to add features, they had better do it without slowing their software. Microsoft is learning this lesson now, with Outlook.

And that brings us to the bigger of the two problems: Development shops don't know how to build lightweight, efficient software.

Software development for the past half-century has been able to rely on Moore's Law and increasing hardware performance. They have spent that time learning how to build software that is reliable. They have spent that time learning how to build software that is readable and maintainable. And they have spent some of that time learning how to build software that is secure. We have invented programming languages to let us build better software: Java for reliability, C# for readability, Rust for security.

With the focus on reliability and readability and security, there has been precious little time for lightweight design. Little time for performance. Consequently, just about all of the knowledge we had for performance in software has retired with the grey-haired programmers from the mainframe age.

It's not merely individuals. Organizations no longer have the knowledge (or even the desire) to build software that performs well. Teams that create the specifications for software don't think about performance. Teams for code design and code review don't think about it, Teams for testing don't think about it.

Side note: There are some teams, in specialized contexts, that do care and think about performance. Embedded systems, telephone switch systems, financial transaction systems, and databases all need high performance. Those teams will be aware of performance and efficiency. But for the rest of us, there hasn't been a need for performance because we have relied on hardware improvements.

Second side note: Ignoring performance for the past half century was a rational choice. Building software that performs well requires time (which is money) and resources (which pull away from new features). New features provided a competitive advantage; faster software did not. Organizations simply followed the money.

Now we have to think about performance.

The first challenge is getting organizations to recognize that performance is important. Some will recognize this on their own; many will see it when customers start complaining. Once they realize that performance is important, different organizations may react differently.

Some organizations may ignore it, hoping that the plateauing of performance is temporary and that advances in hardware will resume. Naive organizations may recognize the need to improve performance and simply add performance requirements to the input of their SDLC (Software Development Life Cycle) and think that the job is done. Organizations that are aware of the intricacies of performance will understand that they face a difficult challenge.

Adding performance closes the Iron Triangle. Without performance requirements, software could be developed relatively easily. The development team could trade off performance for faster delivery, or higher quality. Relying on Moore's Law left one side of the triangle open, essentially a free pool that could absorb the costs of development decisions.

With that side closed, developers must now find solutions which live within the triangle. They cannot use performance as a free token to trade away. They cannot implement new features (with new internal data structures and additional database calls) without considering and working around the performance cost of those structures and calls.

Writing software that performs well is an art. (So is writing software that is readable, and writing software that is correct.) But writing software that is readable, and correct, and performs well is extremely difficult. Many times it is not possible. Compromises must be made to live within the triangle of constraints. If adding a feature requires additional processing, that processing takes time. If adding a feature requires database calls, those database calls take time. If reducing the time for database calls requires more memory (to hold results in a cache) then one gets better performance at the expense of memory. (And some risk, as cache invalidation is a difficult problem.) There are many ways to trade one aspect (performance, cost, quality) for another, but they are trade-offs and one aspect gains while others lose.

How good are organizations at making those trade-offs? How good are development teams at presenting the choices for compromise? How willing are managers to accept the trade-offs provided by the development team and offering guidance for solutions? (Or do managers simply reject the request and mandate a delivered system on the due date?)

With the shortage of hardware and the slowness of hardware improvements, organizations will have to learn to build lightweight software. Doing so requires that they close the Iron Triangle and add performance requirements. Adding those requirements will necessitate communication about software design (more than there is now) and decisions that trade features, quality, and performance. Those conversations require an understanding of the issues and a willingness to compromise.

It is the organizations that prepare for and hold these conversations that will provide the better products.

AI is going to break a lot of companies

Some years ago (never mind exactly) a mentor told me that the difference between a scientist and a businessman was that the scientist wanted to do a thousand things once and a businessman wanted to do one thing a thousand times. That logic still applies today, but AI may present a problem.

Before I talk about AI, let's think about businesses.

Most businesses do like to perform a single thing (such as selling a hamburger) many times. That's a bit of an exaggeration, as hamburger shops like to sell hamburgers with cheese (or without), with fries (or with onion rings), with soda, and sometimes chicken sandwiches instead of hamburgers. But I think you get the basic idea: businesses like to sell a limited set of products or services in a limited set of configurations and make a profit on each transaction.

That idea extends beyond hamburger shops. Auto dealers sell cars, publishers sell books or newspapers, movie studios sell movies, ... the list goes on.

All of these businesses like consistency and stability. While the news changes from day to day and movies have different plots and special effects, to basic idea of selling hamburgers remains the same from day to day, and the basic idea of selling movie tickets remains the same.

Technology has always been a motivator of change. The IBM PC changed the use of computers in businesses. Prior to the IBM PC, most businesses used computers either as large centralized processors of mostly accounting data, with a few exception cases for dedicated word processors or experiments with a TRS-80 or Apple II computer. After the IBM PC, desktop computers were adopted throughout the business world.

But the rate of technological was manageable. IBM (and later Microsoft) limited the changes to hardware and software, and kept old things working with new things. When IBM introduced the PC AT, it required a new version of PC DOS yet it ran almost all programs from the original IBM PC. New versions of Microsoft Windows run almost all programs from the previous versions. The first versions of Windows ran 16-bit DOS programs, too.

Occasionally, a company introduced a product or service that was radically new. Apple brought out the Macintosh computer (or the LISA, an earlier product with similar features) that did not run software from the Apple II. Microsoft released Windows NT which had a completely different architecture and notably did not run many older programs.

These major shifts occurred infrequently, and we always had the opportunity to stay with the older systems for some time. That transition period allowed for gradual upgrades to systems. Most importantly, it allowed businesses to plan upgrades and to operate in a period of known technology. That period provided stability.

Businesses like stability because they can predict the short-term future, and make plans for investments, expansions, new products, and advertising. They can also adjust their supply chains and automate internal processes.

So how does AI affect stability of technology?

In short, AI causes changes in almost every aspect of business, and AI itself is changing rapidly.

When PCs became available, they first replaced typewriters and dedicated word processing systems. The spreadsheet made it easy to analyze data. Later uses included databases and e-mail. Their uses were limited and specific. Their adoption was measured and gradual.

AI, in contrast, can be used in almost any part of the business, from drafting e-mails to analyzing current business conditions to suggesting changes for supply chain management. That means that many areas of the company can change to use AI. That doesn't provide a measured and gradual change.

AI is inconsistent. A request today gets a certain response, a request tomorrow gets a different response (sometimes slightly different, sometimes significantly different). That doesn't provide stability.

The AI engines change frequently. The original IBM PC was first delivered in 1982. The PC XT (almost identical except it included a hard disk) in 1982. The PC AT (with the 80286 processor and a larger hard disk) in 1984. Compaq delivered the 80386-based Desktop Pro in 1987. All of those did basically the same thing.

Today the AI providers (OpenIA, Microsoft, Google, xAI) update their offerings frequently. Those updates are not trivial, and the changes are significant. In some ways, it is like the PC market before IBM announced its PC, with multiple vendors and multiple standards and limited compatibility and consistency.

The frequent changes to AI engines is at odds with the desire of companies for a stable, consistent set of technology on which they can run their business. I don't see it slowing, which means that companies will have to deal with changes (and problems) in their AI purchases. (I also don't see a company that can dominate the market, as IBM dominated the PC market in 1981.)

The changes caused by AI and the ongoing changes in AI products will strain businesses. They will have to adapt to an environment of constant change.

Most won't like it.

Some won't survive it.

AI and Enshittification

"Enshittification" is a term that describes a specific corporate economic activity. In short, products and services start out great for consumers, and over time become more expensive and offer lower quality.

My take: "enshittifcation" is a company adjusting prices and quality to maximize profits. They don't do it to irritate users. They don't do it to annoy employees (enshittification happens to employees too; witness the conversion of employer-paid pensions with employee-paid 401-k plans). Companies "enshittify"products and services to increase profits.

So let's look at AI.

If "enshittification" is simply "maximizing profits", then what will happen to AI services?

The "free" AI services (such as Google's search engine and Microsoft's Bing) will see more advertisements and more sponsored results.

The paid-for services will see... price increases.

I expect that AI services will follow the path set by video streaming services. They will start with simple and inexpensive plans, and then change to include multiple tiers with different capabilities at each (differently priced) tier. Just as video streaming has ad-supported and ad-free tiers, AI will develop tiers, although perhaps not split into ad-supported and ad-free.

And, just like video streaming services, AI services will increase their fees (for all tiers, although perhaps not all at once) over time. And increase them faster than inflation, just like video streaming services.

How high will prices go? If an AI engine can replace a human at certain jobs, then the cost for that AI engine should rise to match that cost. If employers are willing to pay a certain amount for a human to provide coding (for example) then those same employers should be willing to pay just as much for an AI bot to provide coding.

For the AI enthusiasts, these price increases are in a blind spot. I suspect that the enthusiasm for AI in the workplace is driven not by what AI can produce, but by the cost. I also suspect that many employers think that AI costs will remain the same, or roughly the same, over time. They are not expecting the higher-than-inflation cost increases that I am predicting here.

There are, of course, multiple AI services. One can argue that competition will act as a brake on price increases. That doesn't hold for video streaming services, because streaming services are not interchangeable. Each service has its own proprietary content, and that "locks in" customers.

The ability to lock in customers is not immediately obvious for AI services. Today's services are different but also very similar. AI companies may be working on ways to lock in customers, probably by building custom models (or custom weights) for each customer. Or possibly by offering custom APIs for specific capabilities. I'm not sure of the form, but I'm confident that some will be attempted.

In the long term, I think that those who adopt AI will find that it is not as cheap as they thought, and that it will be expensive to move to another (also not so cheap) AI service, and especially difficult to switch back to humans.

AI and the mortgage debt crisis of 2008

In 2008, investment banks saw tremendous losses caused by defaults on mortgages. It wasn't just mortgages; investment companies had bundled and repackaged mortgage loans into securities and sold those securities to other investors. The demand for these mortgage-backed securities was high (they paid good interest) and that demand spurred demand for mortgages, which spurred banks to offer (and originate) mortgages to a large number of people including a large number of people whom they would normally not give mortgage loans. The problem came when interest rates rose, causing mortgage payments to increase (many were adjustable-rate mortgages), and many mortgage holders could not afford the higher payments. They defaulted on the loans, which triggered failures through the entire chain of investments.

The end products, the mortgage-based securities, were supposedly top quality. The mortgages upon which they were based were not; the investment bankers had convinced themselves that a combination of mixed-grade mortgages could support a top-grade investment product.

It was a system that worked, until it didn't.

What does this have to do with AI? Keep in mind the notion of building top-grade products from a composite of mixed-grade products.

AI -- at least AI for programming -- works by building a large dataset of programs and then using that dataset to generate requested programs. The results are, in a sense, averages of certain selected items in the provided data (the "training data").

The quality of the output depends on the quality of the input. If I train an AI model on a large set of incorrect programs, the results will match those flawed programs. By training on large sets of programs, AI providers are betting on the "knowledge of the masses"; they assume that a very large collection of programs will be mostly correct. Scanning open source repositories is a common way to build such datasets. Companies with large datasets of their own (such as Microsoft) can use those private datasets for training an AI model.

I think that averaging to correctness works for most requests, but not necessarily for all requests.

I expect that simpler code is more available in code repositories, and complex and domain-specific code is less common. We can see lots and lots of "hello, world" programs, in almost any programming language. We can see lots of simple classes for a customer address (again, in almost any programming language).

We don't see lots of code for obscure applications, or very large applications. There are few publicly available applications to run oil rigs, for example. Or large, multinational accounting systems. Or perhaps even control software for a consumer-grade microwave oven.

There may be a few large, complex programs available in AI training data. But a few (or one) is not drawing on "the knowledge of the masses". It is not averaging a large set of mostly right code into a correct set of code.

Here we can see the parallel of AI for coding to the mortgage securities industry. The latter built (what it thought were) top-grade investment products from mixed-grade mortgages. The former is building (what it and users think are) quality code from mixed-grade existing code.

But I won't be surprised to learn that AI coding models work for small, simple code and fail for large, complex code.

In other words, AI coding works -- until it doesn't.

Microsoft doesn't know how customers want to use AI

Microsoft has pushed its "Copilot" AI in a lot of places. It's in Windows. It's in Office (excuse me, "Microsoft 365") applications. It's in Visual Studio Code, Visual Studio, and GitHub. If Microsoft has a property, Microsoft has injected Copilot into it.

Little of this (if any) has gone over well with customers. Combined with the injection of advertising, the push of AI has created so much dissatisfaction that customers are leaving Windows for Mac or (gasp) Linux.

A lot has been written (or recorded and posted on YouTube) about this. I won't rehash the arguments here.

What I will ask is this: Why is Microsoft doing this? Why is Microsoft putting Copilot into its products and services willy-nilly, much like it did with the ".NET" label for product names.

I have an idea:

Microsoft doesn't know how customers will use AI, or what they want to do with it.

This is a change for Microsoft. For much of its life, Microsoft has played "catch-up" with technology. After its lead with BASIC, and its fortunate contract with IBM for PC-DOS, Microsoft has been following others. It followed Apple's MacIntosh computers with Windows. It followed a number of database providers with SQL Server. It followed NetScape with Internet Explorer. It followed Java with C#. It followed the iPod with the Zune (look it up). It followed Amazon AWS with Azure.

Now Microsoft is following other AI providers with its Copilot. But those other AI providers are different from Apple and NetScape and Sun Microsystems (the makers of Java). They all knew what their customers wanted, and they provided a solution that met those wants.

Today's providers of AI don't know what their customers want. They don't know how to make a profit from AI. But they are popular and Microsoft is following them, which means that Microsoft doesn't know when their customers want from AI and Microsoft doesn't know how to make a profit from AI.

I find all of this rather unsettling.

 

A flood of used GPUs

It seems to me that we will soon be inundated with a large number of used GPUs. I'm not sure what we are going to do with them, but I suspect that some creative people will devise uses for them.

My idea starts with the data centers used for AI. These are large facilities with lots (thousands, probably tens of thousands) of servers each with one or more GPU. Some are being built as I write this, some have been just recently "turned on", and some are getting old (in terms of technology).

GPUs don't last forever. They suffer from two forms of obsolescence. The first is wear. While GPU chips last quite a long time, other parts of the GPU wear more quickly. Fan motors, capacitors, and other discrete electronic components degrade after significant use.

The second form is capacity, or more specifically the availability of a newer, faster, more efficient GPU. We've seen this in the PC gaming market, with new GPUs announced every year. I myself have benefitted from this phenomenon. A while back, when living in an apartment in Oregon, someone else "donated" an old PC to the recycling area. The PC was mostly complete, with case, power supply, motherboard, memory, and -- interestingly -- a GPU. (The former owner had removed all disk drives, but left everything else.)

GPUs are not cheap, but the former owner thought that the GPU in this PC had little value. I estimate that the former owner had used this PC for about five years.

So let's take that five year figure and apply it to data centers, specifically data centers for AI, because that use lots of GPUs.

What happens after a data center has been online for five years? Technology advances, and there will be newer, faster, more efficient GPUs on the market. The owners of the data center will look at those new GPUs with envy. (Especially the "more efficient" aspect of the new GPUs.)

I predict that some data centers will see their older GPUs replaced. (Perhaps the entire server, not just the GPU.) Which means that the big tech owners of data centers will have a large pile of used GPUs (or servers) sitting on the side.

What to do with those old GPUs? One could recycle them, and I suspect that many will be, but that costs money. They could be buried in a landfill, but that costs money too.

Which leaves another option: sell them.

Selling used GPUs is tricky. You cannot label them as new (not legally). But I suspect that there will be a market for used, recent-model GPUs. We might see a large number of them on the market, which means the price will be relatively low.

Buying used GPUs is also tricky. Used GPUs may fail quickly, and there is usually no warranty.

If you have been pondering a project that uses a GPU (or a number of GPUs), this may be your opportunity to start it.

Microsoft stumbles

Microsoft's attempt to sell AI has been going ... less than spectacularly. It seems that few people want to buy it.

This stumble by Microsoft is a good time to look back at how it has succeeded, and how it has failed, in the past. Microsoft has had a number of successes: BASIC, MS-DOS, Windows, Internet Explorer, Visual Visual Basic, Visual Studio and C#, and Azure. It has also had failures: "Bob" the friendly desktop, "Clippy" the original "AI" assistant, Visual C++, the Zune music player, Windows Phone (both hardware and software), 

Much of Microsoft's success has been built not on technical innovation or product quality. Instead, it was built on marketing and legal agreements.

The first success: BASIC

Microsoft's BASIC was ROM-able; it could be packaged in a ROM and sold as part of a complete PC. That made it attractive to PC manufacturers. A few early PCs used their own versions of BASIC in ROM, but Microsoft's was the most capable. (In this case, Microsoft did have the best product.) Microsoft BASIC became the standard (literally, too; it was adopted by ANSI) and everyone wanted. It was a success driven by the market but also by licensing agreements.

When a manufacturer didn't buy Microsoft's BASIC -- such as Apple -- Microsoft made a plug-in card complete with Z-80 processor and basic interpreter in ROM.

The second success: MS-DOS

Microsoft made a contract with IBM to sell it an operating system, and retained the right to sell that operating system to others. When the IBM PC was released, it immediately became popular as did PC-DOS. (IBM also offered CP/M-86 and USCD p-System for the PC, but higher prices discouraged their adoption.)

The success of the IBM PC, and the success of other computers running MS-DOS (early ones not compatible with the PC, later ones compatible) gave Microsoft a revenue stream and a unique place in the market. Microsoft started setting standards for device drivers and technology to access more that the PC's 1MB memory range.

This success was due to the licensing agreement with IBM, and later licensing agreements with PC manufacturers. Microsoft negotiated a fee for each PC manufactured, regardless of its operating system. Thus, manufacturers had an incentive to include MS-DOS with the hardware.

The third success: Windows

Microsoft gained power with Windows. Microsoft Office, and its superior performance due to API calls not available to competitors. The 'tar baby' effect, in which one Windows product (Outlook) required another Windows product (Exchange). (Or a number of products each requiring SQL Server.)

The fourth success: Internet Explorer

It became popular and the corporate standard. Many web sites advertised "best viewed in IE" and some web sites failed on other browsers.

But since then, Microsoft has had precious few successes. Its notable wins are Azure (capable but still competing with AWS and Google cloud services) and the Surface tablet (premium hardware that shows what is possible and keeps the Windows ecosystem alive). IE's success was relatively short-lived. Google's Chrome rose partly as a revolt against Microsoft. Now Chrome runs the web, IE is gone, and even Edge has Chrome inside.

Microsoft has not designed a successful product (one that became dominant) in the past two decades.

Now Microsoft is pushing AI, specifically "agentic AI". And by "pushing" I don't mean "hawking" but "stuffing down user's throats". Windows 11 is getting agentic AI functions whether you want them or not.

Microsoft's early successes gave them a lot of power in the market. With that power apparently came arrogance, not just a sense of "Microsoft knows best" but "you're going to take this new tech whether you want it or not". Which is just what Microsoft is doing with AI and Windows 11.

But now there are reports of people switching from Windows to Apple (or Linux) to avoid the coming AI. This indicates that Microsoft's market position is not as strong as it was, and that people (when pushed) will choose alternatives. Apple is a reasonable alternative, and even Linux and open source software is capable enough for many office and home functions.

If Microsoft wants to succeed, they must become humble and stop pushing tech onto people. They must shift their mindset from "we know best" to "we've got products that people want". Right now, they don't have products (at least with AI) that people want.

The end of the PC empire

Micron Technology, a large manufacturer of memory DIMMs for PCs, recently announced that it was exiting that business and is redirecting its efforts to memory components for AI server farms.

I think the impact of this announcement is not fully understood.

This change by Micron Technology indicates a larger shift in the industry: away from PCs and towards AI. Away from consumer PCs (desktops and laptops), and also office PCs. The PC, the king of the tech world for decades, has lost its crown.

The IBM PC, announced in 1981, legitimized the then-sputtering tech market for PCs. Before the IBM PC (and for some time after its introduction), PC makers such as Apple, Commodore, and Radio Shack all had to cobble their products together from components available from other systems. Instead of designing the display, the disk, the memory, etc., manufacturers had to survey the market for available components and then design a system with those components. Even the original IBM PC used a keyboard from IBM's System/23 desktop computer system.

But PCs were popular, and manufacturers couldn't ignore the market. They started designing components for PCs. When Microsoft introduced Windows and set hardware standards, the transition was complete: The PC was the center of attention. Standards were set (and followed). Supply chains were built to provide components that met those standards, with robust delivery schedules. One could easily buy components and build PCs.

Some thirty years later, component manufacturers are now looking at the market for AI servers, and they cannot ignore it. Which means that they will pay less attention to the PC market -- or ignore it completely, like Micron is doing.

(I'm rather skeptical of the AI boom, and doubtful that it is sustainable, but that is another question. Micron is placing its bets. I'm assuming that other companies will follow.)

What does this change mean for the PC market? At a minimum, manufacturers of PCs will find it harder to obtain components. Some components will become more expensive. Others will become impossible to find. PC manufacturers may have to submit custom orders for components, or find other sources. It is easy to predict that the price of PCs will rise.

But we may also see fewer PC models, and longer times between announcements of new models. We may see "limited run" announcements in which a new model is available for a limited period of time, or a single production run.

Apple will be somewhat immune to this effect, as they design most components for their PCs. Sourcing components (that is, getting someone else to build Apple-designed components in large quantities) should be possible because Apple's scale is such that one does not ignore it.

But other manufacturers (Dell, LG, HP, etc.) who have relied on the PC supply chain may find their business at risk.

For consumers, I think we will see fewer offerings: Fewer PC models, and fewer configuration options. (Which perhaps may not be such a bad thing. I am often overwhelmed by the number of possibilities when I look for a new PC.)

The game changes for H1-B workers

Donald Trump recently raised the application fee for H-1B visas from $2000 to $100,000. That is a significant change and it affects the calculations for using H-1B visas to obtain labor from other countries. 

The purpose of the H-1B visa program is to admit foreigners with special skills into the US and to use those skills to assist US employers. Over the years, the actual purpose has changed to allow for low-cost workers with some skills (not necessarily rare or special) to work in the US. Employers have used the program as a means of reducing labor expenses.

With the increased fee, the calculations for an H-1B visa change. The increase more than covers the reduction in labor expenses, and the result is that workers on H-1B visas now cost more than native US employees.

Companies have three paths forward (assuming that they do not lobby for exemptions).

First, they can pay the fee and continue to use foreign labor in the US. If they were hiring workers with truly exception skills, this is still a reasonable (albeit more expensive) solution.

Second, they can hire native US workers instead of foreign workers. They have an incentive to avoid this option: It is tantamount to admitting that they used the H-1B visas for cheap labor. It is also a more expensive solution, but perhaps less expensive than continuing with foreign workers on H-1B visas.

The third option is to transfer the workers from the US back to their native countries, and continue to assign them work. This is the least expensive path, but it sets up many companies for morale problems.

Companies have, for the past year and more, asked -- or demanded -- that workers cease remote work and instead work in the office. The explanations from companies have been singular: they need the productivity that comes from in-person collaboration.

If a company sends its H-1B workers "back home" and has them work remotely, then the argument for in-person collaboration is severely weakened and morale among the remaining (in-house) workers will plummet. Managers might explain that contract workers (many H-1B visa holders are contract workers) are less important for collaboration, but this sets up a two-tiered mindset for workers and is probably dangerous in the long run.

If managers allow all workers to work remotely, then their argument for "return to office" falls apart and they look like fools. Managers will do almost anything to avoid looking foolish, so we can assume that remote work for all workers will not happen.

Each company will have to find its own way forward with this change to the H-1B visa program. The decision involves direct expenses for labor and visas, policies for working in the office or remotely, and employee morale.

AI and programmer productivity

In the sixty years of IT, we have seen a number of productivity tools and techniques. Now we're looking at "artificial intelligence" as a way to improve the productivity of programmers. Google, Microsoft, and others are pushing their AI tools upon developers.

Will AI really work? Will it improve programmer productivity? It's not their first attempt to improve the productivity of programmers. Let's look at the history of programming and some of the ways we have improved (or attempted to improve) productivity.

Start with hardware: The first electronic computers were "programmed" by wiring. That is, the hardware was built to perform specific calculations. When you wanted a different calculation, you had to rewire the computer. This was the first form of programming. It's not really an improvement, but we have to start somewhere. Why not at the beginning?

Plug boards: The first productivity improvement was the "plug board". It was a physical board that was plugged into the computer, and it held the wiring for the specific problem. To change a computer's program, one could easily remove one plug board and install a different one. The computer became a general calculation device and the plug boards held the specific calculations - one could call then "programs".

Programs in memory: The next advance was changing the program from wiring (or plug boards) into values stored in the computer. A program consisting of numeric codes could be loaded into memory and then executed. No more plug boards! Programs could be loaded via switches on the computer's front panel, or from prepared paper tapes or punch cards.

Assemblers: But creating the long lists of numbers was tedious. Each operation required its own numeric code, such as 1 to add a number and 5 to store a number to memory. Programmers had to first decide on the sequence of operations and then convert those operations to numeric values. To help programmers (to improve performance) we invented the assembler. The assembler was a program that converted text op-codes into the numeric values that are executed by the computer. (The assembler was also a program that created another program!) Each computer model had its own set of numeric codes and its own assembler.

The first assemblers converted text operation codes to the proper numeric values. But programs are more than just operation codes. Many operations need additional information, such as a numeric constant (for the operation of "add 1 to the accumulator") or a memory address (for the operation "store the value in the accumulator to memory location 1008). It made sense to use names instead of the raw values, so we could write "store accumulator into location named 'total' " as STA TOTAL instead of STA 1008,

Symbols provided to benefits. First, referring to a memory location as "TOTAL" instead of its numeric address made the programs more readable. Second, as the program was revised, the location for TOTAL changed (it was 1008 in the first version, then 1010 in the second version because we needed some memory for other values, and 1015 in a third version). As the real address of TOTAL moved, the symbolic assembler kept up with the changes and the programmer didn't have to worry about them.

Each of those techniques improved productivity and eased the jobs of programmers. But we didn't stop there.

Programming languages: After assemblers, we invented the notion of programming "languages". There were many languages in those early days; Fortran and Cobol are two that we still use today, albeit with enhancements and changes to syntax. We called these "high level" languages to distinguish them from the "low level" assemblers.

We created compilers to convert programs written in high level languages into either machine code or into assembly code (which could then be converted to machine code by the assemblers). We still use high level languages today. We have Rust and Go and C++, which all follow the same process as the early compilers.

But after the invention of programming languages, things changed. The ideas and techniques for improving productivity focussed on the programmers and how they used the compilers, how they stored "source code" (the text programs), and how they interacted with the computer.

Structured programming: Structured programming was not a new language, or a new compiler or assembler, or even a program. It was a set of techniques to write programs that could be better understood by the original author and others. We had decided that programs were hard to read because the sequence of execution was hard to follow, and it was hard to follow because of the GOTO operation, which changed the sequence of control to another part of the program. Avoiding the GOTO became a goal of "good programming". GOTO statements were replaced with IF/THEN/ELSE, WHILE, and SWITCH/CASE statements. These rules were enforced in Pascal (which had a constrained GOTO) and implemented in PL/I, C, and C++ (but they still allowed unconstrained GOTO).

The IDE (integrated development environment:  Prior to the IDE, work on programs was divided between a text editor and the compiler. You would run the editor, make changes, save the file, and exit the text editor. Then your would run the compiler, get a list of errors, and note them. Then run the editor again and fix the errors, then run the compiler again. The development process consisted of alternately running the editor and the compiler. The IDE combined the editor and compiler into a single program, so you could edit and compile quickly. Popularized by Turbo Pascal in the 1980s, they had existed prior in the UCSD p-System. One could even say that BASIC was the first IDE, as it let one edit a program, run the program, and diagnose errors without leaving the BASIC program.

Fourth generation languages: Higher, more abstract than the third generation languages (Cobol, Fortran). SQL is a fourth-generation language, probably the only one we use today. The others were discarded due to poor performance and inability to handle low-level 

Program generators: If compilers take source code and convert it to assembly language (and some of them did), then we can apply the same trick and create a configuration file and feed it into a program generator which generates a program in a third level language (which can then be compiled as usual). Program generators failed bot because they couldn't do the job, but because the very high level languages were very limited in their capabilities. As one colleague said, "program generators do what they do very well, but nothing beyond that".

Source control systems: From the first source control system (sccs) to today's modern tool (git) source control kept previous versions of code and allowed programmers to compare the current version to earlier versions of the code. It allowed programmers to commit changes into a central repository and easily share their updates with other members of the team.

UML (Universal Modelling Language): Similar to program generators, UML was a notation for specifying computation. (The 'U' for 'universal' was the result of combining multiple competing modelling notations.) UML wasn't a programming language -- it wasn't fed into a generator which created the program; instead, it was used by human programmers to create the programs in traditional programming languages. UML was more generic than the configuration files for program generators. But it was not adopted by the industry, for reasons of money, time, and politics.

Object-oriented programming: A way to organize source code for large systems. One might say that it was "structured programming but bigger". Object-oriented programming is one the biggest successes in programming.

Function points: A way to measure the effort to develop programs from the requirements. Function points were a tool not for programmers but for project managers. They calculated estimates for effort, based on easily identified aspects such as inputs, processing steps, and outputs. This was advertised as an improvement over the previous method of intuition or just plain guessing. Function points were unbiased and un-overly-optimistic, and the approach should have been welcomed by managers. Yet managers eschewed function points. There were challenges (tools for all languages were not available, or were expensive) but I believe that the real reason was that the analyses provided by the tools were often higher than managers wanted. Managers did not like the estimates from the function point reports, and reverted back to the older technique of guessing (which could give a number that managers did like).

Looking back, we can see that we have tried various ideas for improving productivity. Many succeeded, some did not.

But from what I've seen, AI seems to be closest to the fourth generation languages and program generators of the past. It creates programs from a specification (an input prompt). Compared to the program generators of the 1970s and 1980s, today's AI tools are much more sophisticated and can generate many more types of programs. Yet they are still limited to the input data used to train them, and AI can go only so far in creating programs. I expect that we will quickly find those limits and become disappointed with AI.

I suspect that AI has a place in programming, probably with junior developers, as aides to develop simple programs. I have yet to be convinced that AI will handle the creation of large-scale, complex systems -- at least not today's version of AI. Future versions of AI may be able to generate large, complex applications; I will wait and see.

A lesson from the 1960s

The recent push for AI (artificial intelligence) is forcing us to learn a lesson -- or rather, re-learn a lesson that we learned back in the early days of computing.

In the 1960s, when computers were the shiny new thing, we adored computers. They were superior at computing (compared to us humans) and could calculate much faster and more accurately than us. Computers became the subject of books, movies, magazine articles, and even television programs. They were depicted as large, efficient, and always correct (or so we thought).

We trusted computers. That was the first phase of our relationship.

Yet after some time, we learned that computers were not infallible. They could "make mistakes". Many problems within organizations were blamed on "computer error". It was a convenient excuse, and one that was not easily challenged. They became scapegoats. That was the second phase of our relationship.

Given more time, we realized that computers were tools, and like any tools, they could be used or misused, that they were good at some tasks and not others. We also learned that the quality of a computer's output depended on two things: the quality of the program and the quality of the data. Both had to be correct for the results to be correct. Relatively few people worked on the programs; more people worked on the data being fed into computers. 

This was the third phase of our relationship with computers. We recognized that their output was based on the input. We began to check our input data. We began to select sources for our data based on the quality of the data. We even invented a saying: "Garbage in yields garbage out".

That was the 1960s.

Fast-forward to the 2020s. Look carefully at our relationship with AI and see how it matches that first phase of the 1960s relationship with computers. AI is the shiny new thing. We adore it. We trust it.

We don't recognize that it is a tool, and like any tool it is good at some things and not others. We don't recognize that the quality of its output depends on the quality of its input.

We build large language models and train them on any data that we can find. We don't curate the data. We don't ensure that it is correct.

The rule from the 1960s still holds. Garbage in yields garbage out. We have to re-learn that rule.

Memory-safe programming needs a simple language

Rust is the pre-eminent language for memory-safe programming. It also struggles to gain acceptance.

But it's not Rust alone that struggles, it is memory-safe techniques that struggles to gain acceptance. If we work from the assumption that memory-safe programming is a good thing (it is), then we face the question of how to ease the acceptance of memory-safe techniques (and memory-safe programming languages). 

Perhaps we could learn from the history of earlier paradigm shifts in programming languages. The adoption of memory-safe programming techniques strikes me as similar to the adoption of structured programming techniques, and the adoption of object-oriented programming. Structured programming was first implemented in PL/I by IBM, and saw only some acceptance in the IBM community. Object-oriented programming was implemented in Simula (in the 1960s, about the same time as PL/I) but became popular with the Java programming language in the 1990s.

There were several reasons not to use PL/I. It was a large and complex language, and difficult to learn. (This was before the days of internet and web pages, so no online tutorials). It was expensive, as you had to buy the compiler and pay for annual support. (And the executables it produced tended to be large and slow.) The reluctance to use PL/I meant a delay for structured programming.

Structured programming eventually did gain acceptance, though not because of PL/I. It was a different language that people used to learn the techniques of structured programming. That language was Pascal.

Pascal was (and in its original form, still is) a simple language. It was (is) a teaching language, specifically for structured programming. It was developed in an academic environment, not a commercial one. It was readily available for the personal computers of the day, in different implementations. Books were readily available. It was adopted by schools (colleges mostly) as an elective and later a required class.

Pascal in its original form was not suitable for commercial applications. Variants of Pascal were developed that did have features to support large applications; Turbo Pascal and Delphi (an object-oriented variant) were the most well-known. Other languages were developed to handle large, commercial applications and eventually surpassed Pascal in popularity. Yet Pascal was a success because it made people aware and comfortable with structured programming.

Structured programming succeeded because Pascal, a small and limited language was readily available and easy to learn.

Object-oriented programming followed a similar path. The early programming languages were difficult to learn, and not always suitable for large-scale applications. Simula, C++, and Objective-C showed that object-oriented programming was possible, given a large effort over a (relatively) long time.

Object-oriented programming did succeed, and like structured programming, its success was due to a smaller and simpler programming language: Java.

Now let's come back to memory-safe programming.

We can think of Rust as the PL/I of memory-safe programming. Rust demonstrates that it can be done, but it is a large language and learning Rust requires a lot of time and effort.

To follow the paths of structured programming and object-oriented programming, memory-safe programming needs a small, easy-to-learn language. I don't see such a language. Right now, it is either Rust or nothing, and that delays the acceptance of memory-safe programming.

I'm not suggesting that we abandon Rust in favor of a small (and impractical for business) programming language. I'm suggesting that we use a small and simple programming language to teach the concepts of memory-safe programming, and then let people move on to Rust. It is the path that structured programming followed. It is the path that object-oriented programming followed. It seems to work.

The missing conversation about AI

For Artificial Intelligence (AI), -- or at least the latest fad that we call "AI" -- I've seen lots of announcements, lots of articles, lots of discussions, and lots of advertisements. All of them -- and I do mean "all" -- fall into the category of "hype". I have yet to see a serious discussion or article on AI.

Here's why:

In business -- and in almost every organization -- there are four dimensions for serious discussions. Those dimensions are: money, time, risk, and politics. (Politics internal to the organization, or possible with external suppliers or customers; not the national-level politics.)

Businesses don't care if an application is written in Java or C# or Rust. They *do* care that the application is delivered on time, that the development cost was reasonably close to the estimated cost, and that the application runs as expected with no ill effects. Conversations about C++ and Rust are not about the languages but about the risks of applications written in those languages. Converting from C++ to Rust is about the cost of conversion, the time it takes, opportunities lost during the conversion, and reduction of risk due to memory leaks, invalid access, and other exploits. The serious discussion ignores the issues of syntax and IDE support (unless one can tie them to money, time, or risk).

With AI, I have not seen a serious discussion about money, for either the cost to implement AI or the reduction in expenditures, other than speculation. I have not seen anyone list the time it took to implement AI with any degree of success. I have yet to see any articles or discussions about the risks of AI and how AI can provide incorrect information that seems, at first glance, quite reasonable.

These are the conversations about AI that we need to have. Without them, AI is merely a shiny new thing that has no clearly understood benefits and no place in our strategies or tactics. Without them, we do not understand the true costs to implement AI and how to decide when and where to implement it. Without them, we do not understand the risks and how to mitigate them.

The first rule of investment is: If you don't understand an investment instrument, then don't invest in it.

The first rule of business management is: If you don't understand a technology (how it can help you, what it costs, and its risks), then don't implement it. (Other than small, controlled research projects to learn about it.)

It seems to me that we don't understand AI, at least not well enough to use it for serious tasks.

All the Windows 10 PCs

Microsoft's Windows 11 is not compatible with much of the existing PCs in the world. Microsoft gave no reasons for such incompatibility, but we can deduce that by specifying a certain level of hardware (processor and memory, mostly) Microsoft was able to implement certain features for security.

Regardless of the reason, a lot of PCs could not move to Windows 11, and therefore stayed on Windows 10. Soon, support for Windows 10 will stop, and those PCs will not get updates -- not even security updates. (Microsoft does offer extended support for a small fee.)

What's going to happen to all of those Windows 10 PCs? Microsoft recommends that you upgrade to Windows 11, and if that is not possible, replace (or recycle) your PC. Here's what I think will happen.

A large number of Windows 10 PCs (perhaps the majority) will stay on Windows 10. People will continue to use the PC, with Windows 10, to do their normal tasks. They won't get security updates, and that they will be okay with that.

Some number of Windows 10 PCs will be replaced. I suspect that this number (as a percentage of Windows PCs) is small. The people who want Windows 11 already have it. A few people may be waiting for the "right time" to upgrade to Windows 11, so they will replace their PCs.

Some number of Windows 10 PCs will be converted to Linux. This may be a smaller percentage than either of the "stay on Windows 10" or "replace" crowds.

I should point out that many PCs that are replaced are then sold to people who resell them. Some will physically destroy the PC, but others simply reformat the disk (or replace the disk) and resell the PC, either with Windows or with Linux. Thus, a PC that is "replaced" can continue its life as a Linux PC.

All in all, the decision by Microsoft to make some PCs obsolete (sort of) will lead to an increase in the number of PCs running Linux.

For me, this decision is personal. I have an old-ish HP laptop which runs Windows 10. It won't run Windows 11 -- even with Microsoft loosening the requirements for Windows 11. I have a decision: keep Windows 10, or switch to Linux. (I like the laptop and want to keep using it.)

Keeping Windows 10 is easy, but offers little benefit. I use Windows for few tasks (most of my work is in Linux) and there are only two items that require Windows: remote access to the office, and administering some old Apple Time Capsules and Airports.

My other option is to convert it to Linux. Conversion is also easy -- I've installed Linux on a number of other PCs. Once converted, I may need to use WINE to run the Apple Airport administration program. (Or I may simply replace the Apple Time Capsules and Airports with modern file servers and routers.) Access to the office isn't that important. The office supplies me with an official PC for access; my personal Windows PC is a back-up method when the official PC fails. (Which it has not done for as long as I can remember.)

So I think I will take up Microsoft's suggestion to get off of Windows 10. But it won't be to go to Windows 11. I have another PC running Windows 11; I don't need two.

Back to the Office

Amazon.com is the latest in a series of companies to insist that employees Return-To-Office (RTO).

Some claim that Amazon's motives (and by extension, any company that requires employees to work in the office) is really a means of reducing their workforce. The idea is that employees would rather leave the company than work in the office, and enforcing office-based work is a convenient way to get employees to leave. (Here, "convenient" means "without layoffs".)

I suspect that Amazon (and other companies) are not using RTO as a means to reduce their workforce. It may avoid severance payments and the publicity of layoffs, but it holds other risks. One risk is that the "wrong" number of employees may terminate their employment, either too many or too few. Another risk is that the "wrong" employees may leave; high performers may pursue other opportunities and poor performers may stay. It also selects employees based on compliance (those who stay are the ones who will follow orders) while the independent and confident individuals leave. That last effect is subtle, but I suspect that Amazon's management is savvy enough to understand it.

But while employers are smart enough to not use RTO as a workforce reduction technique, they are still insisting upon it. I'm not sure that they are fully thinking though the reasons they use to justify RTO. Companies have pretty much uniformly claimed that an office-based workforce is more productive, despite studies which show the opposite. Even without studies, employees can often get a feel for productivity, and they can tell that RTO does not improve it. Therefore, by claiming RTO increases productivity, management loses credibility.

That loss of credibility may be minimal now, but it will hang over management for some time. And in some time, there may be another crisis, similar to the COVID-19 pandemic, that forces companies to close offices. (That crisis may be another wave of COVID, or it may be a different virus such as Avian flu or M-pox, or it may be some other form of crisis. It may be worldwide, nationwide, or regional. But I fear that it is coming.)

Should another crisis occur, one that forces companies to close offices and ask employees to work from home, how will employees react? My guess is that some employees will reduce their productivity. The thinking is: If working in the office improves productivity (and our managers insist that it does), then working at home must reduce productivity (and therefore I will deliver what the company insists must happen).

Corporate managers may get their wish (high productivity by working in the office) although not the way that they want. By explaining the need for RTO in terms of productivity, they have set themselves up for a future loss of productivity when they need employees to work from home (or other locations).

Apple hardware is outpacing Apple software

Something interesting about the new iPhone 16: the software isn't ready. Specifically, the AI ("Apple Intelligence") enhancements promised by Apple are still only that: promises.

Apple can develop hardware faster than it can develop software. That's a problem.

Apple has had this problem for a while. The M1 Mac computers first showed this problem. Apple delivered the computers, with their integrated system-on-chip design and more efficient processing, but delivered no software to take advantage of that processing.

It may be that Apple cares little for software. They sell computers -- hardware -- and not software. And it appears that Apple has "outsourced" the development of applications: it relies on third parties to build applications for Macs and iPhones. Oh, Apple delivers some core applications, such as utilities to configure the device, the App Store to install apps, and low-powered applications such as Pages and Numbers. But there is little beyond that.

Apple's software development focusses on the operating system and features for the device: MacOS and Pages for the Mac, iPadOS and Stage Manager for the iPad, iOS and Facetime and Maps for the iPhone. Apple builds no database systems, has lukewarm support and enhancements for the Xcode IDE, and few apps for the iPhone.

I suspect that Apple's ability to develop software has atrophied. Apple has concentrated its efforts on hardware (and done rather well) but has lost its way with software.

That explains the delay for Apple Intelligence on the iPhone. Apple spent a lot of time and effort on the project, and (I suspect) most of that was for the hardware. Updates to iOS for the new iPhone were (probably) fairly easy and routine. But the new stuff, the thing that needed a lot of work, was Apple Intelligence.

And it's late.

Thinking about the history of Apple's software, I cannot remember a similar big feature added by Apple. There is Facetime, which seems impressive but I think the iPhone app is rather simple and a lot of the work is in the back end and scalability of that back end. Stage Manager was (is) also rather simple. Even features of the Apple Watch such as fall detection and SOS calls are not that complex. Operating systems were not that difficult: The original iOS was new, but iPadOS is a fork of that and WatchOS is a fork of it too (I think).

Apple Intelligence is a large effort, a greenfield effort (no existing code), and one that is very different from past efforts. Perhaps it is not surprising that Apple is having difficulties.

I expect that Apple Intelligence will be delivered later than expected, and will have more bugs and problems than most Apple software.

I also expect to see more defects and exploits in Apple's operating systems. Operating systems are not particularly complex (they are as complex as one makes them) but development and maintenance requires discipline. One gets that discipline through constant development and constant monitoring of that development. It requires an appreciation of the importance of the software, and I'm not sure that Apple has that mindset.

If I'm right, we will see more and more problems with Apple software. (Slowly at first, and then all at once.) Recovery will require a change in Apple's management philosophy and probably the senior management team.

Agile, Waterfall, and Risk

For some years (decades, really), software development has used an agile approach to project management. The Agile method sees short iterations that each focus on a single feature, with the entire team reviewing progress and selecting the feature for the next iteration. Over time, a complete system evolves. The advantage is that the entire team (programmers, managers, salespersons, etc.) learn about the business problem, the functions of the system, and the capabilities of the team. The team can change course (hence the name "agile") as they develop each feature.

Prior to Agile, for some years (decades, really), software development used the "waterfall" approach to project management. The Waterfall method starts with a set of requirements and a schedule, and moves through different phases for analysis, design, coding, testing, and deployment. The important aspect is the schedule. The Waterfall method promises to deliver a complete system on the specified date.

This last aspect of Waterfall is quite different from Agile. The Agile method makes no promise to deliver a completed system on a specific date. It does promise that each iteration ends with a working system that implements the features selected by the team. Thus, a system developed with Agile is always working -- although incomplete -- whereas a system developed with Waterfall is not guaranteed to work until the delivery date.

(It has been observed that while the Waterfall method promises a complete, working system on the specified delivery date, it is quite poor at keeping that promise. Many projects overrun both schedule and budget.)

Here is where risk comes into play.

With Agile, the risk is shared by the entire team, key among these are developers and managers. An agile project has no specified delivery date, but more often than not senior managers (those above the agile-involved managers) have a date in mind. (And probably a budget, too.) Agile projects can easily overrun these unstated expectations. When they do, the agile-involved managers are part of the group held responsible for the failure. Managers have some risk.

But look at the Waterfall project. When a waterfall project fails (that is, runs over schedule or budget) the managers have way to distance themselves from the failure. They can say (honestly) that they provided the developers with a list of requirements and a schedule (and a budget) and that the developers failed to meet meet the "contract" of the waterfall project. Managers can deflect the risk to the development team.

(For some reason, we rarely question the feasibility of the schedule, or the consistency and completeness of the requirements, or the budget assigned to the project. These are considered "good", and any delay or shortcoming is therefore the fault of the developers.)

Managers want to avoid risk -- or at least transfer it to another group. Therefore, I predict that in the commercial space, projects will slowly revert from Agile methods to Waterfall methods.

Google search is broken, and we all suffer

Google has a problem. That problem is web search.

Google, the long-time leader in web search, recently modified its techniques to use artificial intelligence (AI). The attempt at AI-driven search has lead to embarrassing results. One person asked how to keep cheese on pizza, and Google suggested using glue. Another asked about cooking spaghetti, and Google recommended gasoline.

The problem was that Google pointed its AI search engine at the entire web, absorbing posts from various sources. Some of those posts contained text that was a joke or sarcastic. A human would be able to tell that the entries were not to be used in search results, but Google's algorithm isn't human.

Google has rediscovered the principle of "garbage into a computer system yields garbage output".

One might think that Google could simply "pull the plug" on the AI search and revert back to the older mechanisms it used in the past. But here too Google has a problem: the old search algorithms don't work (anymore).

Google started with a simple algorithm for search: count links pointing to the page. This was a major leap forward in search; previous attempts were curated by hand. Over the years, web designers have "gamed" the Google web crawler to move their web pages up in the results, and Google has countered with changes to their algorithm. The battle continues; there are companies that help with "Search Engine Optimization" or "SEO". Those optimizing companies have gotten quite good at tweaking web sites to appear high in searche results. But the battle is lost. Despite Google's size (and clever employees) the SEO companies have won, and the old-style Google search no longer shows meaningful results but mostly advertisement links.

SEO has changed Google search from a generic search engine into a sales lead tool. If you want to purchase something, Google is a great way to find a good price. But if you want something else, Google is much less useful that it used to be. It is no longer a tool for answers to general questions.

That means that search, for the internet, is broken.

It's not completely broken. In fact,"broken" is too strong of a word for the concept. Better choices might be "damaged" or "compromised", or even "inconsistent". Some searches work, and others don't.

Broken, damaged, or inconsistent, Google's search engine has suffered. Its reputation is reduced, and fewer people use it. That's a problem for Google, because the search results is a location to display advertisements, and advertisements are Google's major source of income.

A broken Google search is a problem for us all, in two ways.

First, with Google search broken, we (all) must now find alternative means of answering questions. AI might help for some -- although I don't recommend it for recipes -- and that can be a partial replacement. Other search engines (Bing, Yahoo) may work for now, but I expect that they will succumb to the same SEO forces that broke Google. With no single reliable source of information, we must now turn to multiple sources (stackexchange, Red Hat web pages, and maybe the local library) which means more work for us.

Secondly, the defeat of the Google whale to the SEO piranhas is another example of "this is why we cannot have nice things". It is the tragedy of the commons, with individuals acting selfishly and destroying a useful resource. Future generations will look back, possibly in envy, at the golden age of Google and a single source of reliable information.