Read on Twitter
In favor of the post's point, one thing I've found is that a team of 2 developers in 2020 can very often deliver a high quality system that used to require a cross-functional team of 10 people in 2010. Or 20 in 2000.
But which 2 developers? Any two with the tooling knowledge? No
But which 2 developers? Any two with the tooling knowledge? No
If the industry is moving from "craft" to "knowledge", then it should follow that—regardless of "craft" experience—people with the requisite knowledge about the tools and frameworks and standards available ought to be able to produce quality software predictably. I don't see it.
Instead, the proliferation of (often heavily-marketed) tools over the last decade has done 3 things:
1. Make it easier to start a new app and implement basic features
2. Make it harder to manage complexity as the app grows
3. Convince folks #2 means they picked the wrong tool
1. Make it easier to start a new app and implement basic features
2. Make it harder to manage complexity as the app grows
3. Convince folks #2 means they picked the wrong tool
Q: What's behind this? Why do more & better tools make wrangling complexity harder? And why are we misidentifying intrinsic application complexity as a flaw in whatever framework or stack we're using?
A: Because our conception of dependencies is systemically, dangerously wrong.
A: Because our conception of dependencies is systemically, dangerously wrong.
The allure of dependencies if obvious. You can go 0-to-60 in a weekend. The acceleration feels awesome, especially if your main app is painful.
But those dependencies? They're full of dependencies! It's all become too much to expect each layer to maintain the layers below well.
But those dependencies? They're full of dependencies! It's all become too much to expect each layer to maintain the layers below well.
Hello world app in C? Maybe 6 lines of code atop a minimal but well-maintained stack. If the app grows to 10k lines, it'll look and feel like a mess unless I'm very diligent.
Hello world app nowadays? 6 lines of code _that I write_, but standing on 300 deps and 150k lines. Oof.
Hello world app nowadays? 6 lines of code _that I write_, but standing on 300 deps and 150k lines. Oof.
It would be fine for node_modules to be invisible if we could rely on dependencies to be well-designed & maintained. And if we could trust our tools to upgrade safely & compatibly. Of course, we cannot.
The API surface area of a fresh 2020 app is almost incomprehensibly massive.
The API surface area of a fresh 2020 app is almost incomprehensibly massive.
This is why I visualize dependencies as a Jenga tower, getting taller and shakier each year as we layer more and more transitive dependencies on (and was the thrust of this 2015 talk https://blog.testdouble.com/talks/2014-12-02-the-social-coding-contract/ ). We all ought to weigh a dep's benefits against total cost of ownership
But we can't escape dependency hell, either, because our deployment targets (browsers, largely) have grown in complexity in a sort of a symbiosis with our dependency ecosystem. The bar for shipping a sufficiently modern web app is generally too high to "roll your own" everything.
So where's that leave us? The unenviable position of both needing detailed knowledge of (unreliable, complex) dependencies to accomplish basic tasks AND extreme discipline to manage complexity even more aggressively than if we didn't have those dependencies. More craft, not less.
Back to @jessitron's post. Every few years someone tells us coding will be made obsolete by tooling. Every few years, the tooling does indeed advance, but the amount of code apps need never decreases. If anything, it's harder to write simple, well-organized code as time goes on.
So now the whole industry is trapped. More knowledge is now required, but sweating the details ("craft") is as vital as ever.
Somehow, it's never been easier to get started as a programmer, and yet the bar for achieving each level of relative competence are rising, not falling.
Somehow, it's never been easier to get started as a programmer, and yet the bar for achieving each level of relative competence are rising, not falling.
This is a *worse* timeline than I presented in The Social Coding Contract in 2015. I thought the proliferation of tools would be constrained by a limited tolerance for pain. Instead, most teams are just absorbing that cost and blaming their choice of tool, not the broader system.
All this is made more depressing because the gap between novice & highly-experienced developers seems to be widening, not contracting.
Given an absurd degree of discipline, new tooling can enable one person to create great apps in their spare time (see: https://blog.testdouble.com/talks/2019-05-08-the-selfish-programmer/)
Given an absurd degree of discipline, new tooling can enable one person to create great apps in their spare time (see: https://blog.testdouble.com/talks/2019-05-08-the-selfish-programmer/)
But teams that emphasize "knowledge" at the expense of "craft" inevitably need more and more humans to shoulder the maintenance costs of keeping application dependencies & DevOps at bay… but more people *also* means faster accretion of code complexity, which tools don't address.
Is software becoming a "knowledge" industry? Yes. But it's as much a "craft" as ever.
Becoming a programmer is easier than ever, but becoming a competent programmer is harder than ever. Vexingly, developers' relationship with tools & dependencies is the primary cause of both.
Becoming a programmer is easier than ever, but becoming a competent programmer is harder than ever. Vexingly, developers' relationship with tools & dependencies is the primary cause of both.
If you read this far, be sure to (1) follow @jessitron, who routinely sparks deeply nuanced discussions on software and (2) read her reaction thread: https://twitter.com/jessitron/status/1293995655044780034?s=20
