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.

Last month, Microsoft released a modern remake of its classic MS-DOS Editor, bringing back a piece of computing history that first appeared in MS-DOS 5.0 back in 1991. The new open source tool, built with Rust and simply called "Edit," works on Windows, macOS, and—in a twist that would have seemed unlikely three decades ago—Linux.

The cross-platform availability has delighted longtime users who never expected to see Microsoft's text editor running on their preferred operating system. "30 years of waiting, and I can use MS Edit on Linux," wrote one Reddit user, capturing the nostalgic appeal of running a genuinely useful version of a Microsoft DOS utility on a Unix-like system.

The original MS-DOS Editor represented a major step forward for Microsoft's command-line text-editing capabilities at the time of its release. Before 1991, DOS users suffered through EDLIN, a line-based editor so primitive and user-hostile that many people resorted to typing "COPY CON filename.txt" and hoping for the best. MS-DOS Editor changed that by introducing concepts that seem basic today: a full-screen interface, mouse support, and pull-down menus you could actually navigate without memorizing cryptic commands.

And those cryptic commands persist today in some Linux editors, like Vim, a modal text editor where users must switch between different modes for editing versus navigating text, which famously confuses newcomers. "Many of you are probably familiar with the 'How do I exit vim?' meme," wrote Christopher Nguyen, a product manager on Microsoft's Windows Terminal team, in a blog post about Edit. "While it is relatively simple to learn the magic exit incantation, it's certainly not a coincidence that this often turns up as a stumbling block for new and old programmers."

Aside from ease of use, Microsoft's main reason for creating the new version of Edit stems from a peculiar gap in modern Windows. "What motivated us to build Edit was the need for a default CLI text editor in 64-bit versions of Windows," writes Nguyen while referring to the command-line interface, or CLI. "32-bit versions of Windows ship with the MS-DOS editor, but 64-bit versions do not have a CLI editor installed inbox."

So far, the development community seems to be giving Microsoft's new open source tool a mixed-to-positive reception. But the cross-platform nature of the new tool editor has already excited some developers. "Microsoft released a new terminal text editor! It's called Microsoft Edit, it's open source, it's tiny (about 250KB as a Rust binary) and it works cross-platform," wrote independent AI researcher Simon Willison on X on Saturday. "They built it for Windows 11 - I've been trying it out on my Mac and it's a nice alternative to Vim or nano."

Linux users can download Edit from the project's GitHub releases page or install it through an unofficial snap package. Oh, and if you're a fan of the vintage editor and crave a 16-bit text-mode for your retro machine that actually runs MS-DOS, you can download a copy on the Internet Archive.

When MS-DOS 5.0 launched in 1991, the computing world looked vastly different from today. A typical PC might include a 286 or 386 processor, a mere 4MB of RAM was considered wildly generous, and the Internet remained largely an academic curiosity. Windows 3.0 had arrived the year before, but MS-DOS still ruled desktop computing on IBM PC clones. For millions of users, MS-DOS Editor became their first introduction to "modern" text editing—a stepping stone between the command-line era and the graphical interfaces that would soon dominate.

Looking back to when MS-DOS Editor debuted, it's interesting to learn that the original editor shipped in an unusual form. According to Wikipedia, EDIT.COM was actually just a stub that launched the QBasic programming language editor in a different mode—a clever way to reuse existing code while providing a more approachable text-editing experience. Later versions of EDIT.COM became standalone programs as Microsoft phased out QBasic from Windows distributions.

At 250KB, the new Edit maintains the lightweight philosophy of its predecessor while adding features the original couldn't dream of: Unicode support, regular expressions, and the ability to handle gigabyte-sized files. The original editor was limited to files smaller than 300KB depending on available conventional memory—a constraint that seems quaint in an era of terabyte storage. But the web publication OMG! Ubuntu found that the modern Edit not only "works great on Ubuntu" but noted its speed when handling gigabyte-sized documents.

At a time when AI coding assistants and sophisticated IDEs dominate software development, it's fun to think that we may be on the verge of a renaissance in appreciation for simple, fast tools that just work. After all, some tasks are timeless. The fact that Microsoft's 1991 design philosophy from MS-DOS translates so well to 2025 suggests that most fundamental aspects of text editing haven't changed much despite 34 years of tech evolution.

Booleans are deceptively simple. They look harmless—just true or false, right? What could possibly go wrong? But when you actually use them, they quickly become a minefield.

After many years of coding, I have learned to tread very lightly when dealing with this simple type. Now, maybe you like Booleans, but I think they should be avoided if possible, and if not, then very carefully and deliberately used.

I avoid Booleans because they hurt my head—all of those bad names, negations, greater thans, and less thans strung together. And don’t even try to tell me that you don’t string them together in ways that turn my brain into a pretzel because you do.

But they are an important part of the world of programming, so we have to deal with them. Here are five rules that I use when dealing with Booleans:

1. Stay positive

2. Put positive first

3. No complex expressions

4. Say no to Boolean parameters

5. Booleans are a trap for future complexity

1. Stay positive

When dealing with Boolean variables, I try to always keep their names positive, meaning that things are working and happening when the variable is True. So I prefer expressions like this:

if UserIsAuthorized {
// Do something
}

rather than:

if !UserIsNotAuthorized {
// Do something
}

The former is much more readable and easier to reason about. Having to deal with double negatives hurts the brain. Double negatives are two things to think about instead of one.

2. Put positive first

In the spirit of staying positive, if you must use an if... else construct, put the positive clause first. Our brains like it when we follow the happy path, so putting the negative clause first can be jarring. In other words, don’t do this:

if not Authorized {
// bad stuff
} else {
// good stuff
}

Instead put the positive clause first:

if Authorized {
// Things are okay
} else {
// Go away!!
}

This is easier to read and makes it so you don’t have to process the not.

3. No complex expressions

Explaining variables are drastically underused. And I get it—we want to move quickly. But it is always worthwhile to stop and write things out—to “show your work,” as your math teacher used to say. I follow the rule that says only use && and || between named variables, never raw expressions.

I see this kind of thing all the time:

if (user.age > 18 && user.isActive && !user.isBanned && user.subscriptionLevel >= 2) {
grantAccess();
}

Instead, you should consider the poor person who is going to have to read that monstrosity and write it out like this instead:

const isAdult = user.age > 18;
const hasAccess = !user.isBanned;
const isActive = user.isActive;
const isSubscriber = user.subscriptionLevel >= 2;

const canAccess = isAdult && hasAccess && isActive && isSubscriber;

if (canAccess) {
grantAccess();
}

This is eminently readable and transparent in what it is doing and expecting. And don’t be afraid to make the explaining variables blatantly clear. I doubt anyone will complain about:

const userHasJumpedThroughAllTheRequiredHoops = true;

I know it is more typing, but clarity is vastly more valuable than saving a few keystrokes. Plus, those explaining variables are great candidates for unit tests. They also make logging and debugging a lot easier.

4. Say no to Boolean parameters

Nothing generates more “What the heck is going on here?” comments per minute than Boolean parameters. Take this gem:

saveUser(user, true, false); // ...the heck does this even mean?

It looks fine when you write the function, because the parameters are named there. But when you have to call it, a maintainer has to hunt down the function declaration just to understand what’s being passed.

Instead, how about avoiding Booleans altogether and declare a descriptive enum type for the parameters that explains what is going on?

enum WelcomeEmailOption {
Send,
DoNotSend,
}

enum VerificationStatus {
Verified,
Unverified,
}

And then your function can look like this:

function saveUser(
user: User,
emailOption: WelcomeEmailOption,
verificationStatus: VerificationStatus
): void {
if (emailOption === WelcomeEmailOption.Send) {
sendEmail(user.email, 'Welcome!');
}
if (verificationStatus === VerificationStatus.Verified) {
user.verified = true;
}
// save user to database...
}

And you can call it like this:

saveUser(newUser, WelcomeEmailOption.Send, VerificationStatus.Unverified);

Isn’t that a lot easier on your brain? That call reads like documentation. It’s clear and to the point, and the maintainer can see immediately what the call does and what the parameters mean.

5. Booleans are a trap for future complexity

And you build your system around that Boolean variable, even having Boolean fields in the database for that information. But then the boss comes along and says, “Hey, we are going to start selling medium drinks!”

Uh oh, this is going to be a major change. Suddenly, a simple Boolean has become a liability. But if you had avoided Booleans and started with:

enum DrinkSize {
Small,
Large
}

Then adding another drink size becomes much easier.

Look, Booleans are powerful and simple. I’m old enough to remember when languages didn’t even have Boolean types. We had to simulate them with integers:

10 LET FLAG = 0
20 IF FLAG = 1 THEN PRINT "YOU WILL NEVER SEE THIS"
30 LET FLAG = 1
40 IF FLAG = 1 THEN PRINT "NOW IT PRINTS"
50 END

So I understand their appeal. But using Booleans ends up being fraught with peril. Are there exceptions? Sure, there are simple cases where things actually are and always will be either true or false—like isLoading. But if you are in a hurry, or you let your guard down, or maybe you feel a bit lazy, you can easily fall into the trap of writing convoluted, hard-to-reason-about code. So tread lightly and carefully before using a Boolean variable.

My good old friend and colleague Mike who in the late 2000s built an application for his colleagues that he described as a "content migration toolset." The app was so good that customers started asking for it and Mike's employer decided to commercialize it.

To make that happen, Mike realized his employer would need a licensing system to check that every instance of the app had been paid for.

So he wrote one.

"Excited by the challenge, I spent a weekend researching asymmetric keys and built a licensing system that periodically checked in with the server, both on startup and at regular intervals," he told Me.

The licensing server worked well. Mike told Me that fixing its occasional glitches didn't occupy much of his time.

Requests for new features required more intensive activity, and on one occasion Mike couldn't finish coding within office hours.

"Normally, I left my laptop at the office, but to make progress on the new feature I took it home for the weekend," he told Me.

Mike thought he made fine progress over the weekend, but on Monday, his phone lit up – the licensing app was down, and nobody could log into the content migration toolset.

Customers were mad. Bosses were confused. Mike was in the spotlight.

"Instantly, I glanced down at the footwell of my car, where my laptop bag sat," Sam told Me "And that's when it hit me: the licensing server was still running on my laptop."

It was running there because, as he realized, "I had never transferred it to a production server. For years, it had been quietly running on my laptop, happily doing its job."

Suffice to say that when Mike arrived in the office, his first job was deploying the licensing app onto a proper server!

Last week, Google is feeling like a person at a party trying to look like they're having fun after remembering they left their dog outside. Three researchers with links to Google won the Nobel Prize for their work on AI, cementing the company as an unequivocal leader in the technology at the same time that it’s under antitrust scrutiny from the Department Of Justice(DOJ).

Two of the three people who won the prize in chemistry—Demis Hassabis and John Jumper—are scientists of Google's AI lab, DeepMind. And Geoffrey Hinton, who was part of a duo that won the Nobel for physics, was a Google VP up until last year:

* Hassabis and Jumper won for their work using AI to decode proteins, enabling scientists to rapidly develop medicines and vaccines.

* Hinton won for his work on neural networks—the bedrock of AI systems like ChatGPT.

But these big wins prompted big questions about Big Tech’s increasing and potentially untenable role in scientific development.

That some of the world’s most prestigious scientific awards were given to private sector researchers reflects a paradigm shift—both in what the Nobel Prize committee deems important (clearly AI) and what the future of scientific research will look like.

The research accomplished at DeepMind required unbelievable amounts of computation power and data. Google is one of the only companies that could provide both of those things and bankroll the project.

In his acceptance speech, Hassabis said he wouldn’t have accomplished what he did without the “patience and a lot of support” that he got from Google.

Google is only as big and powerful as its most important businesses, and the DOJ said last week that it is considering asking a judge (who agreed that Google was a monopoly in search) to break up the company. The Justice Department also said it would consider Google’s “leverage of its monopoly power to feed AI” in deciding what to request.

In May, the Army first touted the ceiling of its New Modern Software Development IDIQ vehicle as exceeding $1 billion over 10 years. Then in July, Army officials announced the ceiling will be $10 billion as per a quarterly presentation to industry(More details: https://govtribe.com/file/government-file/2024dccoe006-digital-apbi-slides-for-10-jul-final-for-release-dot-pdf?__hstc=7334573.207ba27471ab70ba49188051ad30dcea.1724253811753.1724253811753.1724253811753.1&__hssc=7334573.3.1724253811753&__hsfp=547971816).

A draft solicitation unveiled Friday sheds further light on the Army's plan to bring in a group of contractors that can perform on rapidly-awarded task orders as they are finalized(More details: https://sam.gov/opp/7aeaa90fce444038962917af5f8859e2/view).

The Army also is increasing the size of the pool it wants to hire, which now stands at a maximum of 20 compared to the original intent of no more than 10 awardees. Up to five of those 20 awards will be reserved for small businesses.

Customization appears to remain a key element of the Army's vision for this contract that emphasizes development practices such as DevSecOps, agile, lean and continuous integration/continuous delivery.

Army leaders plan to use a three-phase advisory downselect process for evaluating the proposals and informing bidders of their standing in terms of likeliness to advance further, but companies can continue on if they like their chances.

The draft RFP also describes how the Army would conduct an on-ramp process to bring more companies into the fold and establish a group of firms called "Awardable but Not Selected."

Contractors in the latter pool appear to be those that just missed the cut for an initial award and will be the first priority for selection in the on-ramp.

Off-ramps are also in the cards for this contract. The Army expects all holders of places on the contract to bid on one-fourth or more of the task orders, plus win one-fourth of the task orders they bid on.

Companies that do not do that will go on probation and can be off-ramped if they do not show improvement within 180 days of being put on notice.

Comments on the draft request for proposals are due by 10 a.m. Eastern time on Sept. 6.