paserbyp: (Default)


Oracle began a new round of layoffs this week, sending early-morning termination emails to staff for the second time in six months.

The latest wave began Monday with affected staff being told, “After careful consideration of Oracle’s current business needs, we have made the decision to eliminate your role as part of a broader organizational change,” according to BusinessInsider. Termination was immediate.

That’s the same wording as in the previous wave of layoffs, which took place on March 31 and affected workers in the US, India, Canada, Mexico and Uruguay. In the 12 months to May 31, Oracle cut its global workforce from about 162,000 to about 141,000, a decline of roughly 13%.

Oracle has made no public statement confirming the latest round of job cuts, but in a regulatory filing days earlier the company said it had set aside a further $700 million for restructuring charges, bringing the total charges this year to roughly $2.8 billion.

Staff receiving the latest termination emails were told termination and compensation details would follow by DocuSign, Business Insider wrote. An internal document reviewed by the publication said severance terms varied by role and region, and some teams facing double-digit percentage cuts.

Affected employees took to social media to vent.

Eric Brunson, a senior principal offensive security researcher at Oracle, described in a LinkedIn post how he had lost access to corporate communication tools before receiving any formal notice. “I woke up to not being able to log back into Slack,” he wrote. “No new emails or notification in email and I’m locked out of there. I was able to get ahold of my manager on LinkedIn and she confirmed.” Brunson said the timing fell two days before a scheduled RSU vesting date, adding, “Probably part of the plan.”

While Oracle is not talking about the layoffs, its 10-Q quarterly report states that management approved and supplemented restructuring plans “to implement certain strategic measures and further improve operational efficiencies, including through the adoption and integration of artificial intelligence technologies across certain functions.” It adds that “subsequent to August 31, 2026, our management supplemented the 2026 Restructuring Plan by approximately $700 million to reflect additional actions that we expect to take.”

Oracle has already spent $1.97 billion of the $2.1 billion restructuring charges it originally budgeted, it reported.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the filing should be read carefully rather than as confirmation of a headcount. “The supplement is an estimate, not a bill,” he said, noting it raises the program’s estimated cost by about a third without committing Oracle to a timetable.

Gogia said the more significant shift is in the filing’s language rather than the dollar figure. Oracle’s August 2025 and February 2026 filings had described the plan as tied to “acquisitions and certain other operational activities.”

AI was named as a driver of restructuring for the first time in the Sept. 11 filing.

Gogia said no verified figure exists yet for how many employees the September round affected.

He noted that 30,000 was a January forecast of the total 2026 program. Twenty-one thousand is the confirmed net decline in Oracle’s global workforce across the full fiscal year. A reported 3,000 job cuts in India on Sept. 1 remains unconfirmed by Oracle.

The $700 million restructuring supplement “cannot be divided into people,” Gogia said, since it covers termination benefits, contract termination costs and other exit costs across a program spanning multiple countries. “There is no solid headcount for the September round,” he said.

Oracle’s first 2026 layoff wave began March 31, when the Revenue and Health Sciences unit, the SaaS and Virtual Operations Services group, and NetSuite’s India Development Centre saw some of the deepest reductions.

Figures published by Oracle for its fiscal year ending May 31, 2026, show research and development headcount fell from 50,000 to 43,000 employees during the year, sales and marketing fell from 31,000 to 25,000, and services fell from 37,000 to 34,000, according to Gogia’s analysis of the company’s own reporting.

International staff, at 92,000, saw a larger reduction than the 49,000-strong U.S. workforce, he said.
paserbyp: (Default)
Java developers have spent decades working with a basic assumption about objects: every object has its own identity. Now, OpenJDK developers are preparing to loosen that rule with JDK 28.

OpenJDK's long-running Project Valhalla(https://openjdk.org/projects/valhalla) has integrated JEP 401, Value Classes and Objects(https://openjdk.org/jeps/401), into JDK 28, where the feature will appear in preview. The change introduces a new category of Java object that has fields and methods like other objects but does not have traditional object identity. The Project Valhalla documentation(https://github.com/openjdk/valhalla-docs/blob/main/site/_index.md?utm_source=chatgpt.com) says the feature is now integrated and available for developers to try in early-access JDK 28 builds.

That may sound like an obscure change to Java's type system. In practice, it addresses a longstanding tension between the programming model developers get from classes and the efficiency associated with primitive values. The idea is that some things represented as objects do not actually need to be distinguished by identity.

A date, for example, is normally interesting because of the date it represents, not because it occupies one particular location in memory. Two objects representing Jan. 23, 1996, can be considered interchangeable for many purposes. Java has historically treated them as separate objects anyway. JEP 401 gives developers a way to tell Java when that distinction does not matter.

Under JEP 401, developers will be able to declare a class using the value modifier. Instances of those classes are value objects.
Value classes are intended for immutable domain values whose instances can be treated as interchangeable when their fields contain the same values. Their instance fields are implicitly final, and a concrete value class is implicitly final as well.

Consider a simple coordinate:

value record Point(int x, int y) {}

Two Point objects containing the same coordinates do not need separate identities. What matters is the value represented by their fields. That differs from Java's traditional object model. With ordinary objects, each execution of new creates an object with an identity that distinguishes it from every other object. Two objects can contain identical data and still produce false when compared with == because the operator traditionally compares their references.

Value objects change that behavior.

The draft Java SE 28 language specification(https://download.java.net/java/early_access/jdk28/docs/specs/value-objects-jls.html) describes special semantics for value objects, including how they are instantiated, compared, and used with synchronization.

For value objects, == determines whether the objects are indistinguishable based on their state rather than whether two references identify the same object. That is one reason JEP 401 is more than a new syntax feature. It changes an assumption embedded deep in Java's object model.

Removing identity gives the JVM additional freedom. If an application cannot tell the difference between two value objects containing the same field values, the runtime does not have to preserve a unique identity for each one. JEP 401 says that freedom can allow JVM implementations to improve memory footprint, locality, and garbage collection efficiency.
For example, a JVM may be able to store the fields of a value object more directly rather than always maintaining the representation required for a conventional identity object. But JEP 401 deliberately does not promise a particular memory layout or optimization.

The proposal says its goal is to give the JVM greater freedom to optimize value objects, not to guarantee that every value class will be flattened in memory or produce a particular performance improvement.

That distinction matters for developers evaluating Valhalla as a performance feature. Declaring something a value class expresses a semantic property, namely that the object does not need identity. What the JVM does with that information is an implementation decision.

Project Valhalla describes its broader goal as combining the abstractions of object-oriented programming with the performance characteristics of simple primitives.

Java's Own Classes Will Change…

JEP 401 is not limited to new classes written by application developers. The proposal identifies 30 classes in the java.* APIs that are being declared as value classes when the preview feature is enabled. They include familiar wrapper classes such as Integer, Long, Double, and Boolean, along with classes including Optional, LocalDate, LocalDateTime, and Duration.

Those are not arbitrary choices. Many of these APIs have already been documented as value-based classes because programs generally should not depend on the identity of their instances. Java has also discouraged identity-sensitive operations on some of them. Since Java 16, for example, developers have been warned against synchronizing on value-based classes.

JEP 401 turns that existing programming convention into a property the JVM can understand. It also introduces methods in java.util.Objects that allow code to determine whether an object has identity or require that an object have identity. Reflection support will also expose the distinction.

That means developers experimenting with JDK 28 may encounter value-object behavior without first writing their own value classes.

The behavior of == is likely to be one of the more noticeable parts of the change.
Consider two conventional objects containing the same information. Java developers know that a.equals(b) may return true while a == b returns false, because the latter tests object identity.

With value objects, there is no identity to test. JEP 401 therefore changes object equality so that value objects with indistinguishable state compare as equal with ==. The OpenJDK proposal is careful not to present this as a general replacement for equals(). It explicitly says that the usual recommendation to use equals() for object comparisons in most contexts still applies.

The difference exists because Java has to define what == means when one of the objects being compared has no identity. That can create compatibility concerns. The JEP warns that changing an existing identity class into a value class can cause behavioral incompatibilities if application code has relied on separately constructed objects being distinguishable through ==.

In other words, code that depends on identity where it should have depended on value may finally have that assumption exposed.

Synchronization Is Another Boundary
Identity also matters to Java synchronization. Traditional objects can act as monitors, allowing code to use constructs such as synchronized (object). A value object cannot serve the same role because it lacks the stable identity required by that locking model.

The Java SE 28 draft specification consequently includes special JVM behavior for monitor operations involving value objects.

This is another reason OpenJDK is introducing the feature as a preview. JEP 401 acknowledges that changes to operations such as == and synchronized could surprise developers or expose bugs in programs that depend on identity-sensitive behavior. The proposal's authors say they expect those disruptions to be relatively uncommon and manageable.

It may be tempting to think of value classes as Java's version of a C struct, but that is specifically not the model Project Valhalla is adopting.
JEP 401 lists introducing a struct feature as a non-goal. Java developers are not being given explicit control over where an object is stored or how its fields are laid out in memory. Value objects remain objects, and value classes remain part of the normal Java class hierarchy.

They are subclasses of java.lang.Object, can implement interfaces, and can be used through Object references. Generic APIs such as List and Comparable can also work with value classes. That approach preserves much of Java's existing object-oriented programming model while giving the runtime new information about which objects do not require identity.

Records are particularly natural candidates. Because records are already final and their fields are final, JEP 401 notes that they are often well suited to becoming value classes.

But records and value classes solve different problems. Records primarily provide a concise way to model data aggregates. Value classes tell Java that the instances themselves do not require identity. A class can therefore be both, as in value record Point(int x, int y).

Project Valhalla has been working toward changes to Java's value model for years, and value classes are only part of that greater effort.
As recently as October 2025, OpenJDK engineer Dan Smith described JEP 401 as fully implemented in a special Valhalla early-access build but said considerable work remained before it could enter a regular JDK release. Developers interested in the feature had to download those specialized builds to experiment with it. Smith's Inside.java post provided an early look at the programming model.

That situation has now changed.

Project Valhalla's current documentation says JEP 401 and its companion work on strict field initialization have been integrated and will be included in JDK 28. Developers can experiment with value objects through JDK 28 early-access builds ahead of the release.

The feature will still be a preview, so developers will have to explicitly enable preview features to use it, and its design can change before becoming permanent. But its arrival in the regular JDK release train represents a significant milestone for Valhalla.

For Java developers, the immediate task is not necessarily to start converting classes to value classes. It is to understand the distinction Java is introducing.

For most of Java's history, being an object has meant having identity. Starting with the JDK 28 preview, those two concepts will no longer always be the same thing.

Apple

Apr. 21st, 2026 08:54 am
paserbyp: (Default)
Apple said yesterday that longtime CEO Tim Cook will step down as CEO later this year and transition to executive chairman of the board. As many on the Street expected, he will be succeeded by John Ternus, currently Apple's senior vice president of hardware engineering. Ternus will take the helm on Sept. 1.

"Investors will view this as mixed, as this was a sudden move to executive chairman [and] there was clearly a push for change at the C-suite. These will be big shoes to fill, and the timing of Cook exiting stage left as CEO could make sense but also creates questions," Wedbush tech analyst Dan Ives said in a note.

Shares fell 1% in pre-market trading on today(Tuesday).

"Apple is making a major transition on its AI strategy, and longtime CEO and legendary Cook leaving now is a surprise. There was growing pressure on Apple to develop a successful AI strategy, and Cook must feel that the pieces are now in place heading into WWDC to hand over the reins at this time. Cook leaves a lasting legacy in Cupertino, and there will be a lot of pressure on Ternus to produce success out of the gates, especially on the AI front."

Here are seven early to-do's for Ternus as Apple CEO. Notching early wins could go a long way in Ternus building Street cred and silencing any doubt he is the right person at the right time to lead the tech giant:

1. Make Apple AI relevant.

Ternus will get a head start on this from Cook, but he needs to build on it and be unafraid to ink other partnerships. Apple and Google (GOOG) recently entered a multiyear partnership to integrate a custom version of the Gemini AI model as the new foundation for Siri and Apple Intelligence. This collaboration is worth an estimated $1 billion annually.

2. Set Apple up for life after the iPhone.

OpenAI officially acquired Jony Ive’s AI hardware startup, io Products, Inc., in May 2025 for approximately $6.5 billion to form its internal devices division. Despite recent shifts in focus, OpenAI (OPAI.PVT) is still expected to release its first piece of hardware with an eye toward challenging the iPhone this year. Ternus has to use his extensive hardware knowledge to think about what life after the iPhone looks like — and it needs to be more than the foldable device rumored to debut later this year.

3. Reset the size of the Apple workforce in the age of AI, like others in Big Tech.

Big Tech players from Oracle (ORCL) to Amazon (AMZN) to Meta (META) are firing people en masse amid pushes to adopt AI workflows. As is customary with a new CEO, Ternus may want to use his new position to resize Apple's workforce and reallocate those savings to growth investments or shareholder-friendly actions. Doing so would give Ternus an early win with shareholders and Wall Street, even though the headlines wouldn't look good. Apple is estimated to have 80,000 workers in the US and more than 160,000 globally.

4. Decide if Apple wants to put more gas on content ambitions to challenge Amazon and Netflix — or pull back.

Apple has spent an estimated $25 billion to $30 billion on original content for Apple TV+ since its 2019 debut. That's a lot of money for not a lot of hits, other than, say, The Morning Show with Jennifer Aniston and Reese Witherspoon and the F1 movie with Brad Pitt. Ternus has to figure out if Apple wants to go all in on content like Netflix (NFLX) and Amazon (AMZN).

5. Refresh the Apple management team.

It's standard practice for any incoming CEO. I suspect he has his preferred management team written up on a doc.

6. Befriend President Trump as Tim Cook did.

Tim Cook has conducted a masterclass in working with the unpredictable Trump. Ternus cannot waste time talking to Trump and investing time in building that relationship.

7. Meet Berkshire Hathaway CEO, Greg Abel.

Berkshire Hathaway (BRK-B) — now led by Greg Abel rather than Tim Cook fan Warren Buffett — holds approximately 228 million Apple shares. The stake is valued at roughly $62 billion, making it the largest single holding in Berkshire’s stock portfolio by a significant margin. It will be good for Ternus to establish a strong relationship with the fellow new CEO Abel. There is nothing like having a Berkshire seal of approval, especially when times get tough.

In additionally, TSMC is reportedly working to build 1-nanometer chips by 2029; Apple could be the big beneficiary.

Apple Silicon has another big journey to take, one that means Apple will probably be the first to introduce 1.4- and 1-nanometer chips inside its systems. If that happens, Macs, iPhones, and iPads will continue to lead the industry in performance per watt.

Why do I say this? Mainly because reports claim TSMC is working to build sub 1nm chips by 2029 — and Apple remains that company’s most important customer, despite competition from AI server manufacturers today.

Demand for AI servers could yet slow, given the looming energy crisis and the trend toward on-prem and edge AI services. I don’t think the current level of investment in AI is sustainable, which is why I think Apple will continue to be TSMC’s lead customer once that bubble, inevitably, bursts.

The latest news is that TSMC intends to begin trial production of its sub-1nm A10 process tech by 2029, setting up Apple to be the first big company to use these new processors inside its hardware when volume production begins.

What’s interesting is that this move to 1nm isn’t just about making transistors smaller, but also about ensuring close integration between chips, memory, and energy systems. A report in 2021 said TSMC was able to reach 1nm by using bismuth instead of silicon in the design.

Apple, of course, already works very, very hard to integrate those different elements on its existing processors, which is why it delivers better performance at lower wattage than competitors. That integration means its systems can accomplish a great deal more from lower quantities of memory, which helps protect the company’s margins against rapidly accelerating RAM prices.

We currently expect up to 30% improvement in both performance and power efficiency from these new chip designs. That implies that iPhone Pro models introduced in 2030 (or possibly 2031) will be powered by these new chips.

TSMC is expected to introduce 1.6nm chips in the next 18 months, though Apple might choose to skip that iteration to guarantee a leadership position once the 1.4nm TSMC process hits in 2028. That iteration will deliver yet another big speed and performance boost to Apple’s devices, with Apple becoming the first PC, tablet, or smartphone manufacturer to ship 1.4nm systems at scale.

What benefits can we expect? During TSMC’s 2025 North American Symposium the company said 1.4nm chips should be 15% faster and consume around 30% less power than the processors inside Apple’s current devices. That’s all good, but it is also interesting to note that the iPhone 17 series hasn’t even made the leap to 2nm as yet, with Apple using TSMC’s N3P process. So, the company has lots of scope to secure the future of Apple Silicon.

If it is correct that Apple will skip TSMC’s 1.6nm process and then climb aboard the 1.4nm and 1nm chips, we could see the two big processor development chapters between now and 2030. This year we can see it introduce 2nm chips, with 1.4nm to follow probably in 2028 and the huge leap to sub-1nm processors to follow in 2030-31.

As these chips will be deployed across Apple’s hardware platforms, including within new designs we don’t know about yet, it means you can anticipate highly significant performance gains wherever in the ecosystem you happen to sit. Whether you’re looking at the next-generation MacBook Neo, MacBook Pro, iPhone or iPhone e, you’ll see impressive performance gains unlocked in all into the last half of this decade.

Those performance gains, combined with improved energy consumption, allows Apple’s hardware designers to work towards thinner, lighter and smaller devices in a range of design configurations — some of which could not have existed before. (Think about spectacles with the kind of performance you once got from a Mac.) The way ahead is clear. Apple has a wide open road for chip design, and while tensions between today’s US and China could derail some of these plans, TSMC’s continued investment in fabrication capacity in the US might help mitigate against even that potential calamity.
paserbyp: (Default)
The computer revolution has always been driven by the new and the next. The hype-mongers have trained us to assume that the latest iteration of ideas will be the next great leap forward. Some, though, are quietly stepping off the hype train. Whereas the steady stream of new programming languages once attracted all the attention, lately it’s more common to find older languages like Ada and C reclaiming their top spots in the popular language indexes. Yes, these rankings are far from perfect, but they’re a good litmus test of the respect some senior (even ancient) programming languages still command.

It’s also not just a fad. Unlike the nostalgia-driven fashion trends that bring back granny dresses or horn-rimmed glasses, there are sound, practical reasons why an older language might be the best solution for a problem.

For one thing, rewriting old code in some shiny new language often introduces more bugs than it fixes. The logic in software doesn’t wear out or rot over time. So why toss away perfectly debugged code just so we can slurp up the latest syntactic sugar? Sure, the hipsters in their cool startups might laugh, but they’ll burn through their seed round in a few quarters, anyway. Meanwhile, the megacorps keep paying real dividends on their piles of old code. Now who’s smarter?

Sticking with older languages doesn’t mean burying our heads in the sand and refusing to adopt modern principles. Many old languages have been updated with newer versions that add modern features. They add a fresh coat of paint by letting you do things like, say, create object-oriented code.

The steady devotion of teams building new versions of old languages means developers don’t need to chase the latest trend or rewrite our code to conform to some language hipster’s fever dream. We can keep our dusty decks running, even while replacing punch-card terminals with our favorite new editors and IDEs.

Here are older languages that are still hard at work in the trenches of modern software development:

FORTRAN

Fortran dates to 1953, when IBM decided it wanted to write software in a more natural way approximating mathematical formulae instead of native machine code. It’s often called the first higher-level language. Today, Fortran remains popular in hard sciences that need to churn through lots of numerical computations like weather forecasts or simulations of fluid dynamics. More modern versions have added object-oriented extensions (2003) and submodules (2008). There are open source versions like GNU Fortran and companies like Intel continue to support their own internal version of the language.

COBOL

COBOL is the canonical example of a language that seems like it ought to be long gone, but lives on inside countless blue-chip companies. Banks, insurance companies, and similar entities rely on COBOL for much of their business logic. COBOL’s syntax dates to 1959, but there have been serious updates. COBOL-2002 delivered object-oriented extensions, and COBOL-2023 updated its handling of common database transactions. GnuCOBOL brings COBOL into the open source folds, and IDEs like Visual COBOL and isCOBOL make it easy to double-check whether you’re using COBOL’s ancient syntax correctly.

Ada

Development on Ada began in the 1970s, when the US Department of Defense set out to create one standard computer language to unify its huge collection of software projects. It was never wildly popular in the open market, but Ada continues to have a big following in the defense industries, where it controls critical systems. The language has also been updated over the years to add better support for features like object-oriented code in 1995, and contract-based programming in 2012, among others. The current standard, called Ada 2022, embraces new structures for stable, bug-free parallel operations.

Perl

Python has replaced Perl for many basic jobs, like writing system glue code. But for some coders, nothing beats the concise and powerful syntax of one of the original scripting languages. Python is just too wordy, they say. The Comprehensive Perl Archive Network (CPAN) is a huge repository of more than 220,000 modules that make handling many common programming chores a snap. In recent months, Perl has surged in the Tiobe rankings, hitting number 10 in September 2025. Of course, this number is in part based on search queries for Perl-related books and other products listed on Amazon. The language rankings use search queries as a proxy for interest in the language itself.

C, C++, etc.

While C itself might not top the list of popular programming languages, that may be because its acolytes are split between variants like plain C, C++, C#, or Objective C. And, if you’re just talking about syntax, some languages like Java are also pretty close to C. With that said, there are significant differences under the hood, and the code is generally not interoperable between C variants. But if this list is meant to honor programming languages that won’t quit, we must note the popularity of the C syntax, which sails on (and on) in so many similar forms.

Visual Basic

The first version of BASIC (Beginner’s All-purpose Symbolic Instruction Code) was designed to teach school children the magic of for loops and GOSUB (go to subroutine) commands. Microsoft understood that many businesses needed an intuitive way to inject business logic into simple applications. Business users didn’t need to write majestic apps with thousands of classes split into dozens of microservices; they just needed some simple code that would clean up data mistakes or address common use cases. Microsoft created Visual Basic to fill that niche, and today many businesses and small-scale applications continue on in the trenches. VB is still one of the simplest ways to add just a bit of intelligence to a simple application. A few loops and if-then-else statements, just like in the 1960s, but this time backed by the power of the cloud and cloud-hosted services like databases and large language models. That’s still a powerful combination, which is probably why Visual Basic still ranks on the popular language charts.

Pascal

Created by Niklaus Wirth as a teaching language in 1971, Pascal went on to become one of the first great typed languages. But only specific implementations really won over the world. Some old programmers still get teary-eyed when they think about the speed of Turbo Pascal while waiting for some endless React build cycle to finish. Pascal lives on today in many forms, both open source and proprietary. The most prominent version may be Delphi’s compiler, which can target all the major platforms. The impatient among us will love the fact that this old language still comes with the original advertising copy promising that Delphi can “Build apps 5x faster.”

Python

Python is one of the newest languages in this list, with its first public release in 1991. But many die-hard Python developers are forced to maintain older versions of the language. Each new version introduces just enough breaking changes to cause old Python code to fail in some way if you try to run it with the new version. It’s common for developers to set up virtual environments, used to lock-in ancient versions of Python and common libraries. Some of my machines have three or four venvs—like time capsules that let me revisit the time before Covid, or Barack Obama, or even the Y2K bug craze. While Python is relatively young compared to the other languages on this list, the same spirit of devotion to the past lives on in the hearts and minds of Python developers tirelessly supporting old code.
paserbyp: (Default)
For decades, programming has meant writing code. Crafting lines of cryptic script written by human hands to make machines do our bidding. From the earliest punch cards to today's most advanced programming languages, coding has always been about control. Precision. Mastery. Elegance. Art.

But now we're seeing a shift that feels different. AI can write code, explain it, refactor, optimize, test, and even design systems. Tools like GitHub Copilot and GPT-4 have taken what was once a deeply manual craft requiring years of hard-fought experience and made it feel like magic.

So, the question on everyone's mind:

Is AI the end of programming as we know it?

The short answer is yes, but not in the way you might think.

To understand where we're going, we must look at where we've been as an industry.

Early computing didn't involve keyboards or screens. Programmers used punch cards, literal holes in paper, to feed instructions into machines. It was mechanical, slow, and very fragile. A single misplaced hole could break everything, not to mention a bug crawling into the machine.

Then came assembly language, a slightly more human-readable way to talk to the processor. You could use mnemonic codes like MOV, ADD, and JMP instead of binary or hexadecimal. It was faster and slightly easier, but it still required thinking like the machine.

High-level compiled languages like C marked a major turning point. Now we could express logic more naturally, and compilers would translate it into efficient machine instructions. We stopped caring about registers and memory addresses and started solving higher-level problems.

Then came languages like Python, Java, and JavaScript. Tools designed for developer productivity. They hid memory management, offered rich libraries, and prioritized readability. Each layer of abstraction brought us closer to the way humans think and further from the machine.

Every step was met with resistance.

"Real programmers write in assembly."

"Give me C or give me death!"

"Python? That's not a language, it's a cult!"

And yet, every step forward allowed us to solve more complex problems in less time.

Now, we're staring at the next leap: natural language programming.

AI doesn't give us a new language. It gives us a new interface. A natural, human interface that opens programming to the masses.

You describe what you want, and it builds the foundation for you.

You can ask it to "write a function to calculate the temperature delta between two sensors and log it to the cloud," and it does. Nearly instantly.

This isn't automation of syntax. It's automation of thought patterns that used to require years of training to master.

Of course, AI doesn't get everything right. It hallucinates. It makes rookie mistakes. But so did early compilers. So did early human programmers. So do entry-level and seasoned professional engineers.

The point is simple. You are no longer required to think like a machine.

You can think like a human and let AI translate.

AI is not the end of programming. It's the latest and most powerful abstraction layer in the history of computing!

So why do so many developers feel uneasy?

Because coding has been our identity. It's a craft, a puzzle, a superpower. It's what we love to do! Perhaps for some, even what we feel we were put on this Earth to do. The idea that an AI can do 80% of it feels like a threat. If we're not writing code, what are we doing?

Thankfully, this isn't the first time we've faced this question.

Assembly programmers once scoffed at C. C programmers once mocked C++, Python, and Rust. Each generation mourns the tools of the past as if they were sacred.

Here's the uncomfortable truth: We don't miss writing assembly, managing our own memory in C, or boilerplate code.

What about API glue? Or scaffolding? Low-level drivers? We won't miss it one bit in the future!

Sure, you may long for the "old days," but sit down for an hour, and you'll quickly thank God for the progress we've made.

Progress in software has always been about solving bigger problems with less effort. The march to adopt AI is no different.

For the last 50+ years, we've been stuck translating human vision into something that machines can understand. Finally, we are at the point where we can talk to a machine like it's a human and let it tell the machine what we want.

As programming evolves, so do the skills that matter.

In the world of AI-assisted development, the most valuable skill isn't syntax or algorithms, it's clarity.

Can you express what you want?

Can you describe edge cases, constraints, and goals?

Can you structure your thinking so that an AI, or another human, can act on?

Programming is becoming a conversation, not a construction.

Debugging becomes dialogue.

System design becomes storytelling.

Architecture becomes strategic planning, done in collaboration with AI and your team to align vision and execution.

In other words, we're shifting from "how well can you code" to "how well can you communicate?"

This doesn't make programming less technical. It makes it more human.

It forces us to build shared understanding, not just between people and machines, but between people and each other.

So, is AI the end of programming as we know it?

Absolutely.

Syntax, editors, or boilerplate code no longer bind us.

We are stepping into a world where programming means describing, collaborating, and designing.

That means clearer thinking. Better communication. Deeper systems understanding. And yes, letting go of some of the craftsmanship we once prized.

But that's not a loss.

It's liberation.

We don't need punch cards to feel like real developers.

We don't need to write assembly to prove our value.

And in the future, we won't need to write much code to build something amazing.

Instead, we'll need to think clearly, communicate effectively, and collaborate intelligently.

And that, perhaps, is the most human kind of programming there is.
paserbyp: (Default)
Elon Musk is creating a direct rival to Microsoft through a new company called “Macrohard.”

“It’s a tongue-in-cheek name, but the project is very real!” Musk tweeted on Friday(More details: https://x.com/elonmusk/status/1958852874236305793).

The CEO of SpaceX and Tesla plans to take on Microsoft by harnessing AI. Musk describes Macrohard as a “purely AI software company” that’ll be tied to his other startup, xAI.

“In principle, given that software companies like Microsoft do not themselves manufacture any physical hardware, it should be possible to simulate them entirely with AI,” he added.

Musk made the announcement weeks after xAI registered the Macrohard trademark with the US Patent Office. Last month, he also said he was creating a “multi-agent AI software company” that would use xAI's Grok chatbot. (In 2021, he also tweeted: “Macrohard >> Microsoft.”)

The goal is to spawn “hundreds of specialized coding and image/video generation /understanding agents all working together,” he wrote. The same AI agents can then emulate human users “interacting with the software in virtual machines until the result is excellent.”

"This is a macro challenge and a hard problem with stiff competition! Can you guess the name of this company?” he wrote at the time.

So, it sounds like Musk is betting AI can replicate and pump out high-quality software, rivaling the Office programs from Microsoft, a company that's betting heavily on generative AI. Last year, Musk also mentioned his plans to use artificial intelligence to create video games.

To develop Macrohard, Musk seems to be leveraging the growing Colossus supercomputer at xAI’s Memphis facility. According to Musk, xAI will buy millions of Nvidia enterprise-grade GPUs as rival companies, including OpenAI and Meta, do the same in their pursuit of cutting-edge AI.
paserbyp: (Default)
Apple is suing YouTuber Jon Prosser for posting details about iOS 26 on his channel(https://youtu.be/YGI8sZqWEl0?si=V7wapwIhPgcuuV_m) earlier this year, which Apple says he acquired through "brazen and egregious" means.

Leaks are nothing new, but in this case, Apple says Prosser worked with Michael Ramacciotti, a product analyst and video editor at NTFTW, on a "coordinated scheme to break into an Apple development iPhone, steal Apple’s trade secrets, and profit from the theft".

Apple alleges that "Ramacciotti needed money," and Prosser promised "compensation in the form of money or a future job opportunity...in exchange for helping Mr. Prosser to access, obtain, and copy Apple confidential information," according to the lawsuit, filed in California district court.

Ramacciotti was friends with Ethan Lipnik, who worked at Apple on unreleased software designs. During a visit to Lipnik's apartment, Ramacciotti figured out the passcode on the development iPhone. Then, when Lipnik left the house, Ramacciotti broke into the phone, called Prosser on FaceTime, and let him see what was on the phone, Apple says. That information was later included in a video posted to Prosser's YouTube channel.

Ramacciotti allegedly used location tracking to see where Lipnik was and make sure he didn't walk in on Ramacciotti sharing details with Prosser.

"According to forensic evidence, Mr. Ramacciotti called Mr. Prosser before he unlocked the Development iPhone, indicating that Mr. Prosser was involved in the decision to improperly access Apple’s trade secrets," according to Apple's lawsuit.

Lipnik didn't find out about this until others "claimed to have seen Mr. Lipnik’s apartment in a video recording from Mr. Prosser," according to Apple's lawsuit. "Only then did Mr. Ramacciotti send an audio message to Mr. Lipnik detailing the compensation proposed by Mr. Prosser and their plan to acquire Apple information," Apple says.

Apple was alerted to the scheme via an anonymous email on April 4. Lipnik also turned over the audio message from Ramacciotti. But even though Lipnik was allegedly duped, Apple still fired him, in part because his work agreement said he was not supposed to leave the development iPhone unattended.

Prosser started his leaks in January, with recreated renders of the new Camera app. Though the renders weren't entirely accurate, the minimalist approach and circular navigation bar were similar to the final product. In a subsequent April video, Prosser leaked a lot more details about iOS 19, including the liquid glass design, the repositioned search and navigation bars, the updated animation for scrolls, and circular app icons. Almost all of those made it to the final iOS build Apple revealed at WWDC 2025.

"Defendants' unlawful acts, which constitute knowing and intentional trade secret misappropriation, have damaged Apple with respect to its competitors, including by giving them the advantage of knowing more about Apple's software designs and unreleased functionality in advance of their release," Apple says in the lawsuit.

Apple seeks to have the court prevent Ramacciotti and Prosser from disclosing any further trade secrets and pay damages.

Prosser denies any wrongdoing. "For the record: This is not how the situation played out on my end. Luckily have receipts for that. I did not 'plot' to access anyone’s phone. I did not have any passwords. I was unaware of how the information was obtained. Looking forward to speaking with Apple on this," he wrote on X(More details: https://x.com/jon_prosser/status/1946056858474525097).

DevOps

Jul. 16th, 2025 09:17 am
paserbyp: (Default)
Despite radical shifts in technology, infrastructure automation has remained largely unchanged. Sure, it’s evolved — from on-prem configurations to cloud and containers — with tools like Terraform and OpenTofu. But the basic premise of declarative configuration management has been around since the 1990s.

“While the tech landscape has changed, the way we think about building automation has not,” says Adam Jacob, CEO and co-founder at System Initiative. “It’s had an incredible run, but we’ve taken that idea as far as it can go.”

Infrastructure as code (IaC) isn’t wrong, but it’s struggling to keep pace with multicloud and scaled devops collaboration. Tools like Terraform rarely offer a one-size-fits-all approach, making configs hard to version and maintain.

“The traditional Terraform or OpenTofu model is very declarative,” says Ryan Ryke, CEO of Cloud Life. “You think, ‘I’m going to build my castle!’ But on Day Two, your castle is falling apart because some developer went in and made some changes.”

At the end of the day, IaC is still just static config files sitting in GitHub repositories that either get stale, or must be regularly reviewed, tested, and updated, becoming a maintenance burden at scale. And because environments always change, mismatches between configs and actual infrastructure are a constant worry.

“Paradigm shift” is a phrase that shouldn’t be used lightly — but that’s the promise of System Initiative. “System Initiative comes closest to a single pane of glass I’ve seen,” says Neil Hanlon, founder and infrastructure lead at Rocky Linux. “Instead of cutting you when you break through, it flexes with you.”

As it stands today, implementing infrastructure as code typically involves a learning curve. “You have to understand all of the technology before you even think about how you can automate it,” says System Initiative’s Jacob.

Engineers typically use tools like Terraform, Pulumi, AWS CloudFormation, or Azure Resource Manager to define and manage infrastructure, versioning configurations in Git alongside application code. But unlike application code, small changes in infrastructure config can ripple across teams — breaking deployments, introducing regressions, and slowing collaboration.

“Configuration programming is worse than application programming, because, if you get it wrong, by definition it doesn’t work,” says Jacob. “You wind up with big, long-running conversations with yourself, the machine, and team members where you’re just trying to figure out how to make it all work.”

Ryke agrees that IaC often leads to toil. “What ends up happening is you spend a lot of time updating Terraform for the sake of updating Terraform,” he says. “We need some sort of tool to rule them all.”

According to Jacob, the deeper problem is that the industry hasn’t treated infrastructure automation as its own domain. Architects have AutoCAD. Game developers have Unity. But devops lacks a comparable standard.

System Initiative aims to change that, as an engine for engineers to build and maintain infrastructure as a living model. “Once you have that engine, you worry less about how to put together the low-level pieces, and more about how to interact with the engine.”

System Initiative turns traditional devops on its head. It translates what would normally be infrastructure configuration code into data, creating digital twins that model the infrastructure. Actions like restarting servers or running complex deployments are expressed as functions, then chained together in a dynamic, graphical UI. A living diagram of your infrastructure refreshes with your changes.

Digital twins allow the system to automatically infer workflows and changes of state. “We’re modeling the world as it is,” says Jacob. For example, when you connect a Docker container to a new Amazon Elastic Container Service instance, System Initiative recognizes the relationship and updates the model accordingly.

Developers can turn workflows — like deploying a container on AWS — into reusable models with just a few clicks, improving speed. The GUI-driven platform auto-generates API calls to cloud infrastructure under the hood.

Infrastructure varies widely by company, with bespoke needs for security, compliance, and deployment. An abstraction like System Initiative could embrace this flexibility while bringing uniformity to how infrastructure is modeled and operated across clouds.

The multicloud implications are especially intriguing, given the rise in adoption of multiple clouds and the scarcity of strong cross-cloud management tools. A visual model of the environment makes it easier for devops teams to collaborate based on a shared understanding, says Jacob — removing bottlenecks, speeding feedback loops, and accelerating time to value.

One System Initiative user is the Rocky Linux project, maker of a free replacement for CentOS, which shifted to CentOS Stream (upstream from Red Hat Enterprise Linux) in late 2020. They’re using System Initiative to build new infrastructure for Rocky Linux’s MirrorManager, a service every Rocky installation uses to find geographically close package mirrors.

Rocky Linux’s community engineers were previously using Terraform, Ansible, and other tools to manage infrastructure piecemeal. But this approach lacked extensibility and posed a high barrier to anyone without deep familiarity. “It made it very difficult to allow other teams to own their applications,” says founder and infrastructure lead Hanlon.

Though still mid-adoption, they’re already seeing collaboration wins. “System Initiative represents a really unique answer to problems faced by open-source organizations like ours, which have fairly decentralized leadership and organization, but where oversight is crucial,” Hanlon says.

Hanlon views System Initiative as a huge force multiplier. “Having a centralized location to manage, inspect, and mutate our infrastructure across any number of clouds or services is an incredibly powerful tool,” he says. “System Initiative will allow our security, infrastructure, and release teams to sleep a bit easier.”

Hanlon especially values how infrastructure is documented as a living diagram, which is malleable to changes and queryable for historical context. For this reason, and others, he believes System Initiative represents the future of devops.

Cloud Life, another System Initiative user, is a cloud consultancy supporting 20 to 30 clients with AWS migrations and IaC. With work highly tailored to each client, they’ve spent years hacking Terraform modules to meet specific project constraints.

“There was never a one-size-fits-all module,” says CEO Ryke. “You could spend a lot of time trying to get everything into a single module, but it was never exactly what we needed for the next customer.”

Terraform adoption has been messy, says Ryke — from public forks to proprietary private modules. Some clients even embed Terraform within source code, requiring hours of updates for small changes.

“Then, you need tooling, and pipelines, and now, the Terraform ecosystem is enormous,” he says. “All to replace a five-minute click if I went into the console.” He’s had enough — battling version changes, back-and-forth with clients, and high project bids for devops maintenance no one wants to pay for. “It’s infuriating as a business owner.”

“The paradigm shift is that System Initiative manages the real world, not just a declarative state — that’s the big change for me.” As a result, Cloud Life made System Initiative the default — bundling it into AWS services, with six new projects last quarter spanning greenfield and migration work.

At the end of the day, end users don’t care about infrastructure maintenance. “Customers can’t give a shit less about Terraform,” says Ryke. “They care about the application and where it runs.” Without a steep Terraform hill to die on, Cloud Life now can hand off a visual model of infrastructure to customers to maintain.

Introducing a new way of working is no quick fix. “We’re fundamentally trying to transform some of the hardest problems,” says Jacob. “It’s not going to happen overnight.”

Because System Initiative is a fundamentally new model, migrations will be challenging for teams with large, prebuilt automations. As with any major technology shift, the transition will involve significant upfront work and gradual progress.

As such, Jacob recommends testing iteratively, observing workflow changes, and replacing parts over time. For now, lower-hanging fruit includes greenfield apps or large-scale deployments that never implemented IaC in the first place.

Preconceptions are another barrier. “A lot of hardcore people are very put off by it,” admits Ryke, comparing it to the original hesitancy about moving into the cloud. “It will upset the ecosystem.”

Jacob is sympathetic, acknowledging that “ClickOps” — i.e., provisioning infrastructure by clicking through GUIs — had its faults. Those paradigms failed because they sacrificed power and completeness for usability, he says. “But if you don’t sacrifice anything, they can accelerate you dramatically.”

For Cloud Life’s purposes, Ryke doesn’t see any sacrifices moving to the System Initiative model. That said, it might be overkill for more predictable, repeatable infrastructure. “When you do the exact same thing every day, the programmatic nature of IaC makes a lot of sense.”

To his point, some teams thrive with Terraform, especially those with stable infrastructure patterns. Meanwhile, other tools are also pushing to modernize IaC — like Crossplane, CDK for Terraform, and OpenTofu modules. Some platform engineering solutions are going further, abstracting infrastructure management altogether.

System Initiative still shows signs of a product in early growth, adds Ryke: some friction points here and there, but a team eager to respond to fixes. He’s hoping for better information retrieval capabilities and broader OS support over time. Jacob adds that cloud support beyond AWS (for Google Cloud Platform and Microsoft Azure) is still on the horizon.

Finally, costs and openness could be potential drawbacks. Although the code that powers System Initiative is completely open source, the product itself is priced. “There is no free distribution of System Initiative,” clarifies Jacob.

Software trends have shifted dramatically — languages have come and gone, release cycles have shrunk from months to hours, architectures have evolved, and AI has taken the industry by storm. Yet the code that automates software deployment and infrastructure has remained largely unchanged.

“The state of infrastructure automation right now is roughly equivalent to the way the world looked before the CRM was invented,” says Jacob.

A skeptic might ask, why not use generative AI to do IaC? Well, according to Jacob, the issue is data — or rather, the lack of it. “Most people think LLMs are magic. They’re not. It’s a technology like anything else.”

LLM-powered agents need structured, relationally rich data to act — something traditional infrastructure tools don’t typically expose. System Initiative provides the high-fidelity substrate those models need, says Jacob. Therefore, System Initiative and LLMs could be highly complementary, bringing more AI into devops over time. “If we want that magical future, this is a prerequisite.”

System Initiative proposes a major overhaul to infrastructure automation. By replacing difficult-to-maintain configuration code with a data-driven digital model, System Initiative promises to both streamline devops and eliminate IaC-related headaches. But it still has gaps, like minimal cloud support, and few proven case studies.

There’s also the risk of locking into a proprietary execution model that replaces traditional IaC, which will be a hard pill for many organizations to swallow.

Still, that might not matter. If System Initiative succeeds, the use cases grow, and the digital-twin approach delivers the results, a new day may well dawn for devops.
paserbyp: (Default)
Here I have assembled some dramatic ERP(Enterprise Resource Planning) flops from over the years and tried to glean wisdom from the wreckage:

1. The Birmingham City Council fails to plan

The Birmingham City Council, in the UK, launched a project in 2022 to replace its SAP ERP with Oracle, with the goal of streamlining payments and HR processes. But a series of missteps, including inadequate project oversight and shifting design requests, have ballooned the cost of the project and led to critical functionality unlikely to be ready by 2026.

The original cost of the project was estimated at about £39 million ($53 million at current exchange rates), but a 67-page Grant Thornton report, released in February 2025, estimated additional costs to be in the £90 million ($123 million) range.

“The impact of the failed implementation has resulted in the Council being without an adequate financial management system and cash receipting system for over two years,” the Grant Thornton audit says.

The blistering audit noted a number of problems with the project, including inadequate project governance, poor design choices, shifting functionality requests, and a shortage of in-house expertise with high turnover.

The project managers failed to report problems in a timely manner, the audit adds. In the pervasive culture surrounding the project, “bad news was not welcome.”

2. Mission Produce: This avocado will self-destruct in five days

Mission Produce packs, ripens, and distributes avocados all over the world, and prides itself on its ability to deliver just-ripe avocados year-round. In November 2021 it turned on a new ERP system intended to support international growth with improved operational visibility and financial reporting capabilities.

Then everything went pear-shaped, and suddenly Mission no longer knew for sure how many avocados it had on hand, nor how ripe they were, with many of them ending up unfit for sale. It had to buy in fruit from other suppliers to meet its delivery commitments, taking a hit to margins. And on top of that, there were delays in its automated customer invoicing.

“Despite the countless hours we spent planning and preparing for this conversion, we nevertheless experienced significant challenges with the implementation,” CEO Stephen Barnard told investors with delightful understatement. “While we weren’t naïve to the risk of disruption to the business, the extent and magnitude was greater than we anticipated.”

The company was forced to develop new processes to keep information flowing around the business, and hire a third-party consultant to sort out the ERP system at a cost of $3.8 million over the following nine months.

That’s nothing, though, to the hit Mission took to its earnings. Attributing an exact cost to the ERP failure is difficult, as the company faced additional challenges from a poor avocado harvest in Mexico around the same time. However, it said that the $22.2 million year-on-year drop in gross profit for the quarter following the go-live was primarily due to the ERP problem.

3. Invacare faces long wait and increased cost for health care ERP intervention

Invacare, a manufacturer of medical devices, has put its ailing SAP upgrade into a coma, temporarily stopping the project — but not the bills.

The company’s North American business unit, which accounts for 40% of its revenue, was the first to move to the new system in October 2021. It didn’t go well, initially limiting online ordering and causing delays in accounts receivable, although things were getting back to normal by the end of the quarter.

ERP pains are a recurring illness for Invacare, which also had problems with an earlier upgrade between 2005 and 2009.

The company is busy restructuring in the wake of the pandemic, simplifying its product lines and adapting its supply chain to the new reality. That’s made it hard for the team working on the ERP upgrade to keep up, so early in 2022 Invacare decided to put the project on hold.

“We wanted to pause on investing in the current footprint, which would only be redone based on how the footprint is revised. And we think that’ll take a couple of quarters to resolve,” chairman, president, and CEO Matt Monaghan told investors in August 2022. “Once we have that template created in North America, that will be deployed globally.”

Even though work on the ERP project has stopped, the company still has to keep paying its systems integrator the same monthly fee, he said.

The ongoing delays and costs appear not to have pleased Invacare’s board, which two weeks later nudged Monaghan out saying the company needed “a change in leadership to oversee the successful execution of Invacare’s business transformation.”

If there’s one thing CIOs can take away from Invacare’s experience, it’s to make sure systems integrators’ contracts don’t require them to be paid when there’s nothing for them to do.

4. Protective packaging firm’s profit takes a knock from ERP

Packaging firm Ranpak’s SAP migration was far from a disaster — it took less than a year and was delivered on time and to budget — but nevertheless initially led to disappointing results.

The move to a cloud-based ERP system came several years into a broader digital transformation at Ranpak.

The company rolled out the new ERP in January 2022, coinciding with its new fiscal year. After a period of planned downtime, “We experienced inefficiencies as we got up the learning curve in the new system,” CEO Omar Asali said in a presentation of first-quarter results.

The software roll-out coincided with Russia’s attack on Ukraine, making it harder for the company to respond to supply chain disruption and increasing input costs. That meant a decline in sales across the board, inefficiencies in processing and shipping, and an inability to increase prices in line with costs, leading to a $5 million drop in net profit in the quarter.

Some of the software issues remained unresolved into the second quarter, and by the end of the third quarter the company had run up $6.5 million in implementation costs. But in early November Asali said the new ERP system had started to deliver better and faster measurement of productivity and KPIs.

5. Snack manufacturer bites off more than it can chew with ERP change

J&J Snack Foods’ ERP problems stem not from a modern system but an older one — Oracle’s JD Edwards.

J&J has long used JD Edwards in its frozen beverages division and decided to move the entire company to the same platform. Unusually, the company decided not to switch ERP systems after closing its books for the year, but in the middle of its second fiscal quarter. For J&J, that was in February, usually a quiet period for snack sales.

February 2022 turned out to be busier than usual, although not for the best of reasons.

“The implementation created unforeseen temporary, operational, manufacturing and supply chain challenges that affected the performance of our food service and retail segments during the quarter,” CEO Daniel Fachner told investors in May. By then, though, the problems were largely resolved and the company was “just fine-tuning a few pieces of it,” he said.

Those challenges meant J&J lost out on $20 million in sales and $4.5 million in operating income. It would’ve been a banner quarter if not for the ERP disruption: The company’s frozen beverages segment, already running JD Edwards, saw sales rise 50%.

6. Haribo’s failure to map workflows

Haribo, a German company famed for creating gummy bears a century ago, began a move to SAP S/4HANA in October 2018. The plan was to convert 16 candy factories across 10 countries away from their standalone ERPs, some of which were decades old.

However, the implementation initially failed to map old business processes and workflows to the new ERP.

Shortly after the new ERP went live, Haribo was unable to track raw materials and inventory, leading to product shortages at grocery stores. Haribo saw a 25% decline in sales of its signature Gold Bear gummy candy in 2018.

7. Leaseplan: A monolith unfit for the emerging digital world

After an initially successful SAP deployment at its Australian subsidiary, in 2016 vehicle management company Leaseplan commissioned HCL Technologies to develop a new SAP-based Core Leasing System (CLS) that was to be the heart of the group’s IT transformation across 32 countries.

In early 2018, auditors warned of exceptions with respect to user access and change management in CLS, and recommended improvements to IT controls and governance as more countries were expected to migrate to CLS that year. By March 2019, things were slipping. The auditors noted that rollout of “the first phases” of CLS was now expected that same year, and added recommendations on managing outsourcing risk to their earlier warnings.

Leaseplan abandoned CLS months later, writing off €92 million ($100 million) in project costs, and millions more in related restructuring and consultancy fees. It managed to salvage just €14 million it had spent on separately developed IT modules that it expected would generate economic benefits in the future.

The problem, Leaseplan said in its second-quarter results, was that CLS would “not be fit for purpose in the emerging digital world in which [it] operated.” The monolithic nature of the SAP system “hindered its ability to make incremental product and service improvements at a time of accelerated technological change,” according to Leaseplan.

Instead, the company planned to build a modular system using best-of-breed third-party components alongside its existing predictive maintenance, insurance claim and contract management systems. It expected this to be more scalable and allow incremental product deployments and updates.

8. Southeast Power Group’s bad data

Southeast Power, an electric infrastructure manufacturer, partnered with SAP back in 2014, with a goal of streamlining its operations by moving its data from its legacy systems into the SAP Business One platform.

The company had planned a deployment date in January 2018, but project deadlines slipped because of corrupted data and confusion about pricing. Because of the data problems, the ERP system being installed couldn’t create accurate invoices, financial statements, and other accounting materials.

The project was not finished four years after Southeast Power contracted with SAP and a systems integrator to move to Business One, even though similar deployments typically take less than a year, according to court documents.

Southeast Power filed a lawsuit in 2018 against SAP and the systems integrator involved in the project. The case against SAP and the systems integrator was dismissed in 2022.

The ERP problems created delays in Southeast Power’s ability to fulfill customer orders on time. The failed project led to delays in the construction of power generators made by Southeast Power and resulted in a loss of company data.

9. MillerCoors: Fighting in public, then making nice

In 2014, MillerCoors was running seven different instances of SAP’s ERP software, a legacy of the years of booze industry consolidation that had produced the alcohol behemoth. The merged company hired Indian IT services firm HCL Technologies to roll out a unified SAP implementation to serve the entire company. Things didn’t go smoothly: The first rollout was marked by eight “critical” severity defects, 47 high-severity defects, and thousands of additional problems recorded during an extended period of “go-live hypercare.” By March 2017 the project had gone so far south that MillerCoors sued HCL for $100 million, claiming HCL had inadequately staffed the project and failed to live up to its promises.

But the IT services company didn’t take that lying down. In June 2017, HCL countersued, claiming MillerCoors was in essence blaming HCL for its own management dysfunction, which HCL said was at the real cause of the failure. Outside observers noted that the wording of the contracts, as outlined in the lawsuits, seemed to be based on a pre-existing general services contract between the two companies, and left plenty of room for error. Then, in December 2018, the two companies resolved the dispute “amicably,” having apparently used the courts as a venue for a high-stakes, public negotiating session.

10. Revlon: Screwing up badly enough to enrage investors

Cosmetics giant Revlon was another company that found itself needing to integrate its processes across business units after a merger — in this case, it had acquired Elizabeth Arden, Inc., in 2016. Both companies had positive experiences with ERP rollouts in the past: Elizabeth Arden with Oracle Fusion Applications, and Revlon with Microsoft Dynamics AX. But the merged company made the fateful choice to go with a new provider, SAP HANA, by December 2016.

Was HANA an undercooked product doomed to fail? Maybe. What’s clear was that the rollout was disastrous enough to essentially sabotage Revlon’s own North Carolina manufacturing facility, resulting in millions of dollars in lost sales. The company blamed “lack of design and maintenance of effective controls in connection with the … implementation” for the fiasco in March 2019. It also noted that “these ERP-related disruptions have caused the company to incur expedited shipping fees and other unanticipated expenses in connection with actions that the company has implemented to remediate the decline in customer service levels, which could continue until the ERP systems issues are resolved.” The crisis sent Revlon stock into a tailspin that, in turn, led to the company’s own stockholders to sue.

11. Lidl: Big problem for German supermarket giant

It was supposed to be the marriage of two great German companies: SAP, the ERP/CRM superstar, and Lidl, a nationwide grocery chain with €100 billion in annual revenue. The two began working together on a transition away from Lidl’s creaky in-house inventory system since 2011. But by 2018, after spending nearly €500 million, Lidl scrapped the project.

What happened? The scuttlebutt centered on a quirk in Lidl’s record-keeping: They’ve always based their inventory systems on the price they pay for goods, whereas most companies base their systems on the retail price they sell the goods for. Lidl didn’t want to change its way of doing things, so the SAP implementation had to be customized, which set off a cascade of implementation problems. Combine this with too much turnover in the executive ranks of Lidl’s IT department, and finger-pointing at the consultancy charged with guiding the implementation, and you have a recipe for ERP disaster.

12. National Grid: A perfect storm

National Grid, a utility company serving gas and electric customers in New York, Rhode Island, and Massachusetts, was facing a difficult situation. Their rollout of a new SAP implementation was three years in the making and already overdue. If they missed their go-live date, there would be cost overruns to the tune of tens of millions of dollars, and they would have to get government approval to raise rates to pay for them. If they turned on their new SAP system prematurely, their own operations could be compromised. Oh, and their go-live date was November 5, 2012 — less than a week after Superstorm Sandy devastated National Grid’s service area and left millions without power.

In the midst of the chaos, National Grid made the fateful decision to throw the switch, and the results were even more disastrous than the pessimists feared: some employees got paychecks that were too big, while others were underpaid; 15,000 vendor invoices couldn’t be processed; and financial reporting collapsed to the extent that the company could no longer get the sort of short-term loans it typically relied on for cashflow. National Grid’s lawsuit against Wipro, its system integrator, was eventually settled out of court for $75 million, but that didn’t come close to covering the losses.

13. Worth & Co.: Interminable rollout leads to a lawsuit at the source

Worth & Co. is a Pennsylvania-based manufacturing company that just wanted a new ERP system, and after hearing several pitches in 2014, decided to hire EDREi Solutions to implement Oracle’s E-Business Suite. The first go-live date was November 2015. But things began to slip. The deadline was pushed back to February 2016. At that point, Oracle demanded that Worth & Co. pony up $260,000 for training courses and support contracts. But 2016 came and went and still no rollout. In 2017 Worth & Co. jettisoned EDREi for another integrator, Monument Data Solutions. Another year was spent attempting, without success, to customize Oracle’s suite for Worth & Co.’s purposes.

Finally, after the project was abandoned, Worth & Co. did something novel in February 2019: they sued not their IT vendor, but Oracle, specifically citing the $4.5 million they paid the software giant for licenses, professional services, and training. The lawsuit is still ongoing.

14. Target Canada: Garbage in, garbage out

Many companies rolling out ERP systems hit snags when it comes to importing data from legacy systems into their shiny new infrastructure. When Target was launching in Canada in 2013, though, they assumed they would avoid this problem: there would be no data to convert, just new information to input into their SAP system.

But upon launch, the company’s supply chain collapsed, and investigators quickly tracked the fault down to this supposedly fresh data, which was riddled with errors — items were tagged with incorrect dimensions, prices, manufacturers, you name it. Turns out thousands of entries were put into the system by hand by entry-level employees with no experience to help them recognize when they had been given incorrect information from manufacturers, working on crushingly tight deadlines. An investigation found that only about 30% of the data in the system was actually correct.

15. PG&E: When ‘sample’ data isn’t

Some rollouts aim to tackle this sort of problem by testing new systems with production data, generally imported from existing databases. This can ensure that data errors are corrected before rollout — but production data is valuable stuff containing a lot of confidential and proprietary information, and it needs to be guarded with the same care as it would in actual production.

In May 2016, Chris Vickery, risk analyst at UpGuard, discovered a publicly exposed database that appeared to be Pacific Gas and Electric’s asset management system, containing details for over 47,000 PG&E computers, virtual machines, servers, and other devices — completely open to viewing, without username or password required. While PG&E initially denied this was production data, Vickery says that it was, and was exposed as a result of an ERP rollout: a third-party vendor was given live PG&E data in order to fill a “demo” database and test how it would react in real production practice. They then failed to supply any of the protection a real production database would need.

16. Waste Management disputes vendor’s promises

Waste Management, a waste removal services provider, launched an enterprise-wide ERP project in 2005, scheduled to go live in 2007.

The company’s goal for the new ERP was to simplify and automate its order-to-cash processes and move them away from outdated workflows and legacy IT systems.

Waste Management chose SAP for the project. According to Waste Management, the ERP vendor touted as an out-of-the-box solution that could be implemented with minimal customization.

SAP also allegedly told the company that it could achieve up to $220 million a year in benefits from a consolidated ERP system that could be ready to go live in 18 months. After the ERP project didn’t go as planned, Waste Management disputed that it worked as advertised.

Waste Management filed a $100 million lawsuit against SAP, alleging, among other things, that the ERP vendor showed off a software mockup modified to look like it was fully functional. Waste Management later amended the lawsuit to see $500 million in damages.

17. The US Navy’s four siloed pilot projects

Beginning in 1998, the US Navy attempted to launch four separate and independent ERP pilot projects meant to modernize the organization’s supply chain, acquisition and financial management operations, and other functions.

By 2005, the Navy had spent about $1 billion on the pilots but had not created a unified ERP. The pilot projects were not interoperable, even though they overlapped, because of inconsistent designs and implementation, according to the US Government Accountability Office. The $1 billion was largely wasted, the GAO said, although Navy leaders disputed that assessment.

The Navy eventually worked with SAP to deploy a consolidated ERP. Three of the four pilot ERPs were scrapped and replaced with a single SAP ERP, with an estimated cost of $800 million.

18. Hershey’s rushed timelines

This ERP failure is an old one, but it had a huge impact on the company. Back in 1996, concerned about the effects of the Y2K bug on its legacy systems, Hershey’s decided to replace its ERP.

Aiming for an integrated ERP environment, Hershey’s chose three separate software solutions, SAP’s R/3 ERP, Manugistics’ supply chain management (SCM) package, and Seibel’s CRM. Hershey’s pushed for a 30-month deployment to beat possible Y2K complications, despite the vendors recommending a 48-month timeframe.

The systems went live in July 1999, three months behind schedule, during a busy time of the year for Hershey’s in the lead up to Halloween and Christmas. Hershey’s cut corners on testing, leading to systems integration problems.

With the systems not working as intended, Hershey’s was unable to process more than $100 million in candy orders, even though most of the products were in stock.

The mess led to a 19% decline in quarterly profits and an 8% decline in stock price in a single day. Annual revenue dropped by 12% from 1998 to 1999. Between October 1998 and October 1999, the company’s stock price dropped by 35%.







Bottom line is don’t fall afoul of regulators, make sure your data is secure and clean, and document your processes before you move to a new platform — all good advice for any rollout or any other big IT project, really.

Profile

paserbyp: (Default)
paserbyp

October 2026

S M T W T F S
    1 23
4 5 6 7 8 910
11121314151617
18192021222324
25262728293031

Most Popular Tags

Syndicate

RSS Atom

Style Credit

Page generated Oct. 11th, 2026 05:08 am
Powered by Dreamwidth Studios