Marlinspike on Agile and Security
Brandon Vigliarolo (Hacker News):
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.
[…]
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.
[…]
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.
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.
[…]
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.
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.
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.
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.
See also: Peter Naur and ncharity.
Previously:
3 Comments RSS · Twitter · Mastodon
I think what type-A, self-driven people like Marlinspike underestimate is that a lot - perhaps the majority - of developers also like this system, because it means they can come to the office at 9, work on their clearly defined tasks, go back home at five, and never spend a second thinking about what they actually did, or why. If it goes wrong, they're not responsible, because they did the thing that the task told them to do.
This is a fundamental problem with our economic system, where most people have no ownership in their work. This is fine when you're assembling a car, because it's a bad thing when people get creative with how they glue together the accelerator pedal assembly. But it's terrible for software engineering, and it's probably a major reason why companies like Google haven't had a successful, novel home-grown product in years and years.
I happen to like agile as in that thing described in the agile manifesto. I've yet to see it "implemented" by a company because of fairly obvious reasons, management wanting to know how much time is left being one of them.
The issue isn't agile, or even the bastardisation of agile. It is that proper development takes a looong time to arrive at something that can be achieved quickly if you settle for "good enough for now".
This issue (crappy things fast beats solid things slow) is spread way beyound software development and to tackle it we need to dismantle capitalism.
Yeah, I dunno. I think there's much to the argument that both software and people have become far too stratified and abstracted and that this contributes to churn and ambivalence. This isn't at all healthy.
But on the other hand, there's a lot of narcicism in IT, a lot of NIH syndrome, and of course computing is a place where theory makes practice and abstractions and tooling are genuinely powerful (witness the move toward safer languages, e.g.). And, yes, I know I say this a lot, but Marlinspike just happens to think that standards don't matter and hold back innovation (that he doesn't feel standards processes can accommodate, presumably).
So I am sceptical of this sort of absolutist reductionism. There's some truth in it, but beware the narcicists!
