From cybersecurity and big data to cloud computing, IT Brew covers the latest trends shaping business tech in our 4x weekly newsletter, virtual events with industry experts, and digital guides.

IT Brew

Software Development

Billy Hurley

itbrew.com

Software engineer Joshua McKenty had worked on enough open-source projects by 2010 to know that the Global Earthquake Model (GEM) was not on a path to being open source.

With stints at NASA, Netscape, and a consultancy leveraging open-source tech, McKenty had experience designing publicly collaborative code, using a shared, continuous-release philosophy known as 

He and the earthquake scientists knew their teams could use a little Agility.

Helen Crowley, former researcher and GEM’s secretary general, said scientists at the time only 

“For us, it meant maybe you would make your software available somewhere at the end, once it was ready for other people to look at. But I think what Josh really explained to us is that it had to be 

McKenty shared how he helped to turn GEM—and develop its software engine OpenQuake— into an open-source, community-driven initiative, literally bringing together two teams that hadn’t always shared the same spaces: developers and scientists. The process involved a lot of Agile, which in theory meant iterative development and in practice meant offsites in the mountains and paired programming at desks.

“I focused a lot more on cultural transformation, rather than just, ‘Let’s produce software and feel proud of ourselves,’” he told us.

In 2010, McKenty was asked to review the then-in-progress Global Earthquake Model, which at the time was on year two of a five-year grant.

The GEM team wanted to create an open-source model to estimate earthquake-related impact and calculate human or economic losses for a collection of assets—the kind of tool that could help everyone from city planners to insurance providers.

“You need to have a first release now, not at the end of five years, so that you build a community around the software,” he remembers. That meant changing development practices.

McKenty took a six-month contract as interim secretary for IT—moving to Italy and occasionally commuting to the GEM office in Switzerland.

The definition of software, McKenty says, is it will be wrong—often because of a communication problem between the person with the problem and the engineer building the solution.

And that lack of cooperation exists at a wide range of organizations, not just the ones making earthquake models.

A global survey of 3,500 developers, published in July by Atlassian, found 55% of knowledge workers had difficulty tracking down information despite knowing a lot of people at their job,” and 56% said their companies “plan and track in different ways, which makes it hard to collaborate.”

Principles in the Agile manifesto, created in 2001, include tenets like delivering working software frequently, collaborating with business and developers, and reflecting regularly.

McKenty saw an occasional lack of agility (there’s that word again) in the methods of scientists, who often need their software to work just once in a lab, McKenty said. An 

, however, had to work constantly for a world of contributors.

In those six months, McKenty shook up the team, focusing on collaboration. It was not uncommon for a scientist and programmer to pair up on a task like simulating the shaking of the Earth. With this setup, no one had to wait for an email about which of a library’s many algorithms best resembled earthquake movement.

“You understand the science and I understand the software, and let’s make that work minute by minute, instead of month by month, or requirement by requirement,” he told us.

With McKenty at the helm, GEM’s team of coders and scientists produced a new feature or version every two weeks—what Agility proponents often call “sprints.”

Crowley remembers an offsite code sprint in Switzerland—“a weekend featuring lots of couches and pizza and just a good atmosphere.”

During McKenty’s tenure, the team had 20 or 30 releases, McKenty said, that culminated in OpenQuake 1.0’s release in 2013.

The GEM Foundation’s OpenQuake has been used in recent years to determine risk profiles for public schools in Peru, roads in Solomon Islands, and buildings in San Francisco. In December 2018, GEM “

 with a total of 30 national and regional seismic hazard models.”

“I am more proud of OpenQuake than anything else I’ve ever worked on, because I spent six months and I got the community in this sort of shape, and I let it go,” he said.

McKenty is currently CEO at fraud prevention company Polyguard.

Agile, as a practice, is hanging in there, even as the idea of paired programming these days might involve a vibe coder and their LLM.

 from this year polled global pros with knowledge of their company’s Agile practices and found that 61% of respondents have been using Agile practices for over five years, and 24% have deployed them within the last three years.

The ability to work in agile, cross-functional teams is increasingly important to IT pros, according to McKenty, who sees the source of good, working software as a collaboration between human teams talking to each other, sharing spaces, and trying to close up a gap that’s always open.

“I think that’s the definition of every software project; usually the product owners or the customer have an understanding of what they want, but not how to make it happen, and the software team has an understanding of how to make it happen, but not actually what they want. And so building good software is about being able to communicate across that divide.”

How to build an earthquake model: Bring scientists and software engineers together (literally)

 Joshua McKenty shares his Agile approach with Global Earthquake Model (GEM).

Caroline Nihill

The link between music and math has been long known; musical notes are the representation of vibrations and frequencies, which math quantifies. The art of music—the way it makes us feel—is how our brains recognize and translate patterns and then translates them into feeling and emotion.

Adam Ribaudo, an artist and IT professional, said that he’s always felt an intuitive link between math and music, specifically when it comes to intuition and harmonies.

“There needs to be some sort of intuition and some mental map of how notes relate to each other,” Ribaudo said. “That mental map can then be transferred more easily to mathematical or some technical concepts where you’re searching in your brain for those harmonic registries.”

Technology, says composer, musician, and technologist Chester Jankowski, is about turning abstractions into patterns. So it’s not all too surprising, then, that musicians frequently make great technologists, coders, and IT professionals, according to 

. Each organization points to how musical artists think and problem solve logically and mathematically.

Jankowski and Ribaudo, along with other musicians who work in IT, say that the overlaps between logic and creativity assist them in both composing code and music. In order to improvise in music, for example, you have to know the foundation of music—how notes and keys work, etc. The same holds true in IT: In order to fix a system, you have to know the infrastructure.

When Wolfgang Wedemeyer, a ServiceNow senior staff software engineer and musician, is in the midst of working or composing, he doesn’t always see the connection between his expertise in music and software until later. Once he’s reflected on an experience, he can begin to connect the two.

“I get into a very similar flow state when I’m working creatively on music and when I’m also working on solving some of the harder software problems,” Wedemeyer said. “When it comes to theory and rules and patterns and all that sort of stuff, I find there’s similarities between doing parallel programming and working on harmonies, where you have to keep multiple things that are happening simultaneously in your head and make them work together in a logical way.”

Jankowski pointed back to the intuition for problem-solving, and said that musicians are often skilled at seeing the “bigger picture.”

“If something’s broken…you could either just go through a checklist and check everything in order, or sometimes you just have this flash of insight,” Jankowski said. “You’re able to go there and retrace your steps.”

Director of software engineering management at ServiceNow,Yaron Guez, told IT Brew that the translation of skills is more subtle. He believes that programming languages and music theory are the same in that both require certain rules to be followed.

“I haven’t had a moment where, because I know this circle of fifths or the way music modes work…that’s going to help me specifically on this programming challenge,” Guez said. “It’s just the same type of problem-solving, or rather, the same type of understanding another language.”

Guez said that in encountering different technologists who are also musicians, he finds that those individuals are often the ones where “this isn’t just math to them.”

“Not to say that math doesn’t have creative elements to it—of course, when it comes to proofs and whatnot—but still, they’re not just following a set of instructions and relying on their knowledge and expertise to do it,” Guez said. “They’re using creative problem-solving to figure it out.”

A close-up of a person's hands playing electric guitar chords with AI data patterns overlaid.

What music and coding have in common: Math

“It’s just the same type of problem-solving, or rather, the same type of understanding another language.”

Brianna Monsanto

The AI tools industry execs say that can make you more productive may actually be holding you up.

 by AI research nonprofit METR, which found that experienced developers who used AI tools in their workflow took 19% more time to complete assigned tasks.

 The researchers conducted a randomized controlled trial among 16 seasoned developers. Between February and June, the developers completed 246 tasks on popular open-source repositories that they were regular contributors to, such as the Mirror of the Glasgow Haskell Compiler and Hugging Face Transformers library. Participants were able to use any AI tool of choice and were compensated for their time.

Researchers recorded the screens of participants as they completed their assigned tasks. They then used the screen captures, as well as “rich statistics from source-code management systems” and interviews and surveys with participants to better understand the results. Some of the factors researchers attributed to the longer work time included participants overusing AI tools, believing they would improve productivity; existing familiarity with repositories, rendering AI tools less useful; and unsatisfactory outputs, leading participants to spend extra time trying different prompts or tinkering with AI-generated code.

Prior to starting the study, the developers predicted that AI would speed up their completion time by 24%. Their confidence in how much the tools would reduce their workflow fell slightly (20%) after participating in the study.

 The researchers of the study state that the factors they alleged contributed to the discovered slowdown are study-specific, and it should not be assumed that AI tools do not have practical real-world applications.

“These results do not imply that current AI systems are not useful in many realistic, economically relevant settings,” the study’s authors wrote. “Furthermore, these results do not imply that future models will not speed up developers in this exact setting.”

” continues to gain popularity in the industry and developers embrace generative AI and LLMs in their workflows. A 

 found that more than three-fourths (76%) of developers used or planned to use AI tools in the development process last year.

Michael Armstrong, CTO at Authenticx, told IT Brew that the nonprofit’s discovery on AI tools tacking on time for some developers was unsurprising. He said he has personally seen occasional productivity losses when AI tools are introduced due to a variety of reasons, including learning curves, substandard quality, and distractions created by these tools.

“What I’ve observed is you can have a really, really good coder, but if they don’t really understand what they’re trying to solve for…the results are not ideal,” Armstrong said.

Meanwhile, David Murray, CEO of talent platform Confirm, said the study validated what he and his team had experienced in their own workflow slowdowns, citing 

 and developers tinkering with AI-generated code. He said it has influenced how he advises his team to work with AI tools.

“The guidance that we’ve kind of given each other is basically [to] be mindful and give very specific instructions and focus on specific use cases.”

a clock split into three different pieces, like a pie chart

AI coding tools might actually be slowing you down

METR found that seasoned developers took 19% longer to complete tasks when using AI tools.

Anthropic and Meta both won landmark cases concerning copyright infringement in two Northern California district courts in late June, signalling the beginning of the fight on fair use between AI companies and creators.

The law firm McDermott Will & Emery wrote 

 that both companies showed the use of copyrighted materials in LLM training is highly transformative. The decision in the case against Meta also signified a new battleground surrounding market-harm evidence, as the authors were not able to show data that tied the company’s AI, Llama, to a loss in book sales or licensing value.

The post said appeals for the cases are “virtually certain,” and concluded that while companies wait on clearer appellate laws, they should “assume that training on text obtained from dubious sources remains a high-risk activity and that a lack of market-harm evidence may be only a temporary shield.”

Anthropic’s case included the use of pirated material to create its central library, which will be subject to another trial, according to the judge’s decision.

Three authors (Andrea Bartz, Charles Graeber, and Kirk Wallace Johnson) had their work copied by Anthropic through both pirated and purchased sources, according to the filing.

The company used the unauthorized copies to train LLMs and kept library copies in place as a permanent and general-purpose resource, “even after deciding it would not use certain copies to train LLMs or would never use them again to do so.”

Judge William Alsup, who oversaw the case against Anthropic, said that the evidence provided did not prove any non-transformative use of the work through its model, Claude.

“Yes, Claude could help less capable writers create works as well-written as [the plaintiffs’] and competing in the same categories,” Alsup wrote. “But Claude created no exact copy, nor any substantial knock-off. Nothing traceable to [the plaintiffs’] works.”

Alsup said that the use of the books to train Claude was “exceedingly transformative” and was fair use under the Copyright Act.

Judge Vince Chhabria, who oversaw the Meta case, also pointed out that the tech giant’s use of 13 authors’ works was transformative. He 

 that while a company is more likely to be protected by fair use doctrine, there isn’t a rule saying that this “inoculates you from a claim of copyright infringement.”

Chhabria continued that under the fair-use doctrine, the market harm for copyrighted work is “more important than the purpose for which the copies are made.” He continued in the conclusion that Meta’s use of the authors’ works presented no meaningful evidence on market dilution “at all.”

The plaintiffs in this case contended that Llama is capable of reproducing snippets of text from their books and that Meta’s use of their works for training without permission diminished their ability to license work for training LLMs.

“Both of these arguments are clear losers,” Chhabria wrote. “Llama is not capable of generating enough text from the plaintiffs’ books to matter, and the plaintiffs are not entitled to the market for licensing their works as AI training data.”

Anthropic and Meta both win landmark fair-use cases surrounding LLM training

Authors took the companies to court concerning the use of copyrighted materials in LLM training—judges agreed that the tech’s final product was “transformative.” 

Back in the ’90s, Rob Brown, 48, now director of foundation engineering at employee-experience platform Workleap, wasn’t bagging groceries. He was coding them.

The teenage software engineer in training was working part-time for a supermarket in Ontario, Canada, when he created an inventory management system. Brown used a programming language called Turing, a general-purpose language developed in 1982, to bring his “little pet project” to life.

“That was almost a commercial application in my young imagination,” Brown told us.

If he had to do that kind of app today, he said, he might use a 

, backed by a cloud service, and then integrate a large language model (LLM) to help managers or customers with questions.

On his desk today, Brown keeps a Mac mini for running LLMs locally. With loaded tools like Transformer Lab, he is experimenting with using Workleap’s post-mortem transcript calls as training data for determining the root causes of customer-impacting incidents. Whether digitally organizing grocery ingredients or client headaches, Brown remains curious and wants to apply his skills to the technology of the moment.

“That passion to actually keep up and reapply those skills and to continually reinvent ourselves is important,” Brown said.

Being a veteran software engineer doesn’t mean you can’t vibe with the 

. Programmers who began their coding careers decades ago shared how they’re embracing coding changes and actively experimenting with AI—because that’s what developers do. They keep up.

“When you get into being a programmer or engineer, you have to sign up for change,” John Pettit, 47, CTO at Promevo, told us. “It’s not, ‘I learned one time and I’m done.’”

Pettit began his engineering career in the ’90s Windows NT era, he said, building simple apps for companies like insurance offices and automotive shops, using early text editors and compilers. Since then, he’s seen coding evolve with the arrival of integrated development environments, intermediate languages, dynamic web pages, mobile apps, and now agentic AI.

Pettit recently participated in a hackathon to use Google’s Gemini model to 

 that delivers commentary for specific Major League Baseball games. The project combined a front-end of well-known HTML, CSS, and JavaScript with newer components like Google’s text-to-speech API.

 found 76% of just under 61,000 global respondents are using or plan to use AI tools in their development process, an increase from previous year’s percentage of 70%.

Rather than run from AI, Stephen Bennett, 42, director of Soliant Consulting’s cloud-native applications practice, encourages his team of seven coders—all with at least a decade of experience, he said—to integrate AI into their build practices.

Bennett, who started his software engineering career in 2005, and the Soliant software crew began experimenting with LLMs in October 2024. Now they use tools like StackBlitz’s Bolt to quickly generate front-end designs, with “caution,” he noted, emphasizing the importance of reviewing output and securing client data.

“My approach is that it’s not going anywhere. We need to learn,” Bennett told us.

In addition to highlighting an increased usage of AI tools, the 2024 Stack Overflow study revealed plenty of rookie engineers. One-third of developers surveyed have coded for four years or less. Just over one-quarter of respondents had 15-plus years of professional coding experience.

Scott Petry, partner at PwC in cloud engineering consulting services, says it’s actually the junior engineers who are struggling to gain the benefits of AI coding assistants.

A crew of seasoned coders who know their way around evolving code environments can help bring pet projects to production.

“When you want to build a production-grade app, you still need to have a group of deep engineers who understand the facets of building a good application, getting the architecture right, getting the overall system put together the right way,” he said.

Coding workspace with dual monitors and laptop featuring programming and development tools. (Credit: ATHVisions/Getty Images)

How curious veteran coders keep up (and reinvent themselves) with AI

Experienced programmers know a thing or two about adapting.

was a young programmer for a pager company, he learned a valuable lesson that many veteran coders have likely learned, too:

If the weekend is almost here, don’t touch anything.

“If you really want to anger the gods of software, deploy new software on a Friday afternoon,” Thomas, now SVP of engineering at KnowBe4, told us, recalling how a well-meaning colleague at the time had wanted to optimize a database by changing indexes, but did not change all of the code that 

Software at that pager company connected a customer relationship management (CRM) network to a network of pagers. The changes accidentally took down the CRM system, Thomas said, and there was the risk that two million customers could not manage their devices.

“It was what we call a potential extinction-level event. I mean, it was that type of bug,” he told us, remembering working the weekend to solve the problem.

Veteran coders like Thomas spoke with us about the coding bugs that can ruin a Friday or a whole weekend—and what mechanisms (like emergency rollbacks) should be in place before everyone heads to happy hour.

A bug—“the bane of every developer’s existence,” according to Clinton Walker, associate director of delivery at Presidio—generally refers to code that doesn’t work as intended.

A bug can lead to unexpected consequences, ranging from error messages to downed CRMs.

Recent research from digital infrastructure advisory organization Uptime Institute found that 40% of 397 global data center operators and vendors experienced a “significant, serious, or severe IT service outage” caused by human error over the past three years. Top reasons reported by the IT practitioners included failure to follow correct procedure.

Also, according to Uptime: Sixty-one percent of a surveyed 207 respondents said a “software or configuration” error within the same time period led to an outage caused by a problem with a third-party IT service provider.

Bugs happen—even to the Mars Climate Orbiter, which burned up following a failure to use metric measurement in the coding of a software file, according to 

Walker recommends many practices to prevent bugs, including 

 tools followed by manual review from a senior engineer.

Dave Laskowski, director, application development and engineering at Protiviti, suggests modern 

 pipeline tools like Azure DevOps and plenty of 

, or short pieces of code written to run the main functional code and verify its output. “A good developer will write multiple unit tests with different inputs to thoroughly validate critical functions,” he wrote in an email to IT Brew.

KnowBe4 deploys strict access controls for code tweakers, no matter the rank.

“Even I, as the SVP of engineering here at KnowBe4, don’t have permission to make a code change, merge that code change to our production branch, and ship that,” Thomas told us. “There are probably about four or five different software systems in between that would block me from doing something so reckless.”

After the call, he shared in an email other measures the company implements, including built-in automation blocks for production changes unless a certain number of engineers have reviewed and approved the modifications, as well as tools that can roll back disruptive code updates.

And, of course, there’s engineering policy to make sure everyone has a good weekend.

“Every engineer is fully aware that it is a violation of company policy to deploy changes after a certain time on a Friday,” Thomas wrote.

A hand dropping a laptop with code on the screen falling out of it. (Credit: Illustration: Anna Kim, Photos: Adobe Stock)

How to prevent software bugs from ruining your weekend

 IT pros share some old horror stories of accidental disruption.

Tom McKay

Earlier this year, Wikipedia got a makeover.

Since January, the online encyclopedia—which, according to its Wikipedia, is available in 333 language editions, boasts over 300,000 active editors, and is the seventh-most popular website in the world—has presented itself to the world through the Vector 2022 skin, the first major update since the original Vector rolled out in 2010. The changes, including more white space, a relocated search bar, and a new table of contents, are immediately visible to anyone who’s spent a good amount of time browsing the site.

The main point of Vector 2022 wasn’t to dramatically alter the Wikipedia experience, but to address some longstanding issues with the site’s user interface. Any changes made by the nonprofit that runs Wikipedia, the Wikimedia Foundation, had to be vetted by the site’s international user base of editors, readers, and other volunteers who write the articles.

The foundation’s paid design team was composed of about half a dozen engineers, an engineering manager, a data analyst, a designer, and a community relations specialist, Wikimedia Foundation Lead Product Manager Olga Vasileva told IT Brew. Additionally, they have volunteer community ambassadors who handle outreach to groups like contributors to Farsi or Vietnamese-language Wiki.

Vasileva said that since the rollout of Vector 2010, the Wikimedia Foundation had focused primarily on the experience of its rapidly growing mobile readership, which included large numbers of young people and those living in regions where cell phones remain the primary method of internet access. The desktop experience lagged behind as a result, both in terms of technical improvements and usability for an increasingly diverse user base.

Based on consultation with members of Wikipedia projects across the globe, the design team found key areas for improvement generally fell within readability and usability, as well as ways to onboard new users into greater engagement (like writing articles). In many cases, volunteers had already developed CSS customizations and gadgets to improve Wikipedia, though those plugins remained largely obscure to general readers.

Primary changes included adjusting the width of text—data showed users were reading Wikipedia slower than other websites—and fixing messy site navigation by clustering buttons across pages. Vasileva’s team also rebuilt the table of contents so that it no longer appears within the article text, but on a sidebar that remains visible as users scroll the page. Vasileva said that was one of her favorite changes.

“The new table of contents is used 54% more than the previous one for logged-in users, and 47% more for logged-out users,” Vasileva told IT Brew. “That’s just a huge impact.”

“They’re getting to the stuff that they need a lot quicker, and the information that they need a lot quicker,” she added. “That’s really important to us.”

The modernization of the Wikipedia layout had other benefits as well, such as providing opportunities to reorder the document object model and reduce the amount of unnecessary code.

“Our performance team uses a suite of metrics and tools to analyze the new skin,” Jan Drewniak, senior UX engineer, told IT Brew via email. “The 

 using Web Page Replay are promising as they show performance improvements over the old skin. Among other things, it’s increased our speed index score from 1600 to 1510, despite the fact that the JS and CSS payloads have increased and overall full page load times have stayed the same.”

Drewniak told IT Brew one major consideration was the possible impact Vector 2022 might have on Wikipedia’s caching infrastructure, which the site relies on heavily to support high volumes of traffic. Wikipedia runs a “pretty traditional” LAMP stack (Linux, Apache, MySQL, PHP) backed by Varnish as its front-end cache, according to Drewniak.

“About 90% of our anonymous traffic (ie, page-views by users who do not log in to Wikipedia) is served directly from our Varnish caching layer, so any large-scale disruptions to that layer would put severe strain on our application servers,” Drewniak wrote. “In order to minimize this impact, we had to deploy the new skin incrementally.”

The changes haven’t been without controversy: A community debate over whether to switch Wikipedia’s default to Vector 2022 last year peaked at over 

, while debate raged on other pages as to whether to 

“But of course as soon as we deployed, we’'ve had so many conversations about like, ‘Hey, can you help me fix this gadget,’ or, ‘Hey, I want to write a script that does this,’ or ‘I want to change this in this way,’” Vasileva told IT Brew. “But it’'s been really fun… to, just because we’'ve seen people do stuff with the new skin that we would have never really thought to do that fits their workflows in different ways.”