{"id":44647,"date":"2024-08-27T21:02:05","date_gmt":"2024-08-28T01:02:05","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=44647"},"modified":"2026-01-07T15:11:13","modified_gmt":"2026-01-07T20:11:13","slug":"marlinspike-on-agile-and-security","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/08\/27\/marlinspike-on-agile-and-security\/","title":{"rendered":"Marlinspike on Agile and Security"},"content":{"rendered":"

Brandon Vigliarolo<\/a> (Hacker News<\/a>):<\/p>\n

Marlinspike opened the second day of Black Hat with a talk that was ostensibly supposed to be a fireside chat with Black Hat founder Jeff Moss, but the Signal founder stole the show with an opening chat laying out a case for reclaiming the “magic” of software development that’s been lost after 20 years. That loss, he argued, was due to stuffing developers into “black box abstraction layers” that strip them of the freedom needed to be innovative.<\/p>

[…]<\/p>

Instead of allowing developers to operate from the bottom up in a way that lets them combine engineering expertise with the vision to see new capabilities in existing technology, agile teams end up siloed, working separately from each other, and without much visibility into what other teams are doing, he argued.<\/p>

[…]<\/p>

While software engineering has spent the past few decades struggling to become quicker, more flexible and, by extension, more abstracted, security researchers have been doing the opposite, said Marlinspike.<\/p><\/blockquote>\n\n

Jon Snader<\/a>:<\/p>\n

\n

He blames its current deplorable conditions on Agile but what he really means is layers and layers of abstraction that prevent the developer from understanding what is really happening with their software.<\/p>\n

[…]<\/p>\n

The difficulty is that our corporate industry leaders love this stuff because it enables them to produce loads of software faster and easier. The problem is that no one, including the developers, really understand what it’s doing. The result is exploit after exploit. And, as Marlinspike says, a lack of joy on the part of those writing the software.<\/p>\n<\/blockquote>\n\n

smokel<\/a>:<\/p>\n

\n

Here's a theory on why (some form of) Agile is problematic: Subdividing work into smaller parts is typically beneficial. However, in computer programming, this approach often fails because even the smaller tasks require some creativity, and unexpected challenges are likely to arise.<\/p>\n

The person who did the subdividing gains a lot of insight while breaking down the larger problem. However, when transferring a portion of the work to a developer, much of this knowledge is inherently lost. The developer must then devise a creative solution, and lacking the necessary information, may either come up with a suboptimal solution or need further communication with the original architect.<\/p>\n

There is no clear-cut solution. Some might argue for more experienced developers who have all the necessary knowledge readily available in their heads. Others might advocate for better design diagrams and documentation to capture all the relevant information. Ultimately, it requires careful consideration, or luck, to strike the right balance. But the dogmas of Agile certainly aren't helping much.<\/p>\n<\/blockquote>\n\n

See also: Peter Naur<\/a> and ncharity<\/a>.<\/p>\n\n

Previously:<\/p>\n