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.
